Agile mk-journal-issue-004


Published on

Writing Good Requirements
How Do You Recognise
Good Requirements Definition?
We started the discussion by trying to establish
how we’d identify that good requirements had
been defined. i.e. if you look at a particular product
or project, how would you know that requirements
had been well defined?
Firstly, we agreed that in order to state that good
requirements had been written, the business case,
return on investment, business objectives or drivers
of the project or product would have to have been

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile mk-journal-issue-004

  1. 1. Agile:MK Journal Agile:MK Journal March 2013 ISSUE 04 A special interest group for professionals from the Milton Keynes area who are interested in learning, sharing and encouraging the use of agile methodologies such as Scrum, Extreme Programming & Lean Thinking. Next Meeting “Waterfall v Agile” Monday 29th April 2013 6pm – 8pm Sponsored by
  2. 2. Agile:MK Journal March 2013 Agile:MK User Group Welcome to the March edition of the Agile:MK Journal. The Agile User Group in Milton Keynes meets once a month to share and learn about agile methods through real-world experiences. Each month we’ll Steve Garnett publish a brief overview of the discussions Founder Agile:MK and insights of the group in this journal. To register your interest, If you’d like to join the group so you can please join the attend the sessions, and be involved in the LinkedIn Group at discussions face to face, to learn or share agile-mk-liug your experiences, please join us on LinkedIn. Next meeting “Waterfall v Agile” Monday 29th April 2013 6pm - 8pm Jurys Inn Hotel, Midsummer Boulevard, Milton Keynes, MK9 2HP Agile:MK Journal, design & produced by endjin
  3. 3. Agile:MK JournalWriting Good RequirementsHow Do You Recognise Good Requirements Definition? PeopleWe started the discussion by trying to establish More important than how to go about something how we’d identify that good requirements had is ‘who’ should do the job? If we agree with the been defined. i.e. if you look at a particular product first statements that good requirements are or project, how would you know that requirements demonstrable in the achievement of stated businesshad been well defined? objectives, then surely whoever will be defining the requirements should have excellent understanding Firstly, we agreed that in order to state that good of the business domain, the market, customers andrequirements had been written, the business case, revenue generating drivers of the market, the product return on investment, business objectives or drivers or project is geared toward.of the project or product would have to have beenmet… This may seem a simple statement… In order to write successful requirements someone with excellent business domain understanding should be engaged. Yet, I have seen numerous ‘strategic projects’ being sourced by junior Business Analysts, or Product Owners who are new to the company and its markets. When we then consider the ‘time-bound’ nature of achieving good requirements realisation, then we need to source people who understand the technical domain and how to rapidly deliver product to the required quality level of the market. Typically, it is rare to find people that have both in-depth market and customer knowledge as well as in-depth technical expertise – they exist, but are rare and quite rightly are expensive. So most companies find themselves trying to solve the problem of creating a single delivery team, that is capable of producing a product, that brings together both excellent business domain knowledge, as well as technical expertise. The Voice of the Customer Lean thinking is founded on identifying and AND that these business objectives had been met understanding the customer, so in understanding within a suitable timeframe in order to realise the requirements, it is essential to identify the “Voice benefits and reduce any lost revenue opportunities of the Customer”. Or to put this another way, from taking too long to define the requirements or how will you ensure that you are creating a deliver the value articulated product that a customer wants and will pay for?The ‘Why’ of the project or product needs to be There are many ways to understand what your clear and is just as important (if not more so) than customers want from your business and we the what. Finally, we agreed that the objectives discussed a few of these as examples:need to be quantified, which led us into stating that they should be Specific, Measurable, Achievable, In some business models it is possible to have Relevant & Timebound (SMART). direct customer communication and involvement, with products being created bespoke or tailored specifically for a customer. However, when serving
  4. 4. Agile:MK Journala mass market understanding the needs of company, I used CS data to direct technology and millions of users requires different approaches. process change. Customer Services is a direct link to your customers and not only that, it is a direct Customer forums and social media are becoming link to what customers think of your operation, more prevalent methods of gathering and eliciting the problems they are facing using your services feedback, and gauging the needs and behaviours or products and should therefore be the first port of customers. In the e-commerce industry user of call for establishing or measuring operational behaviour workshops and user experience testing performance.are utilised to understand how products are used and how to improve them whilst they are being developed. Multi-variate testing (MVT) is also Visionused by e-commerce companies as a means of optimising website design. Often seen as a fluffy artefact and difficult to define, we created a mind-map of our thoughts in an attemptMVT is a way of serving consumers with different to get a joint understanding of Vision and its purpose.designs of the same page i.e. 10 customers could each see a different style/design of a product page. A Vision defines “What we will look like when we MVT software then tracks how effective each get there…” It is a blueprint, it is the future. A Vision design is in terms of user goals and presents this can come in many formats - stories, pictures, data in real-time. The company can then control statements, videos and visuals.which designs are presented in real-time and improve the overall profitability of the website. This led to a discussion about representational systems from Neuro-Linguistic Programming (NLP) practices. NLP proposes that we all interpret data both incoming and out-going through our representational system. This system is how we sense and live in the world. The different ways we ‘sense’ the world are visual (sight), auditory (hearing), kinaesthetic (emotions/feeling), olfactory (taste), sensory (touch), and auditory digital (inner-voice/internal logic). The olfactory and sensory systems are not easily adaptable to creating vision, however, appealing to someone’s sight, hearing, feelings or logic is possible which is why influencers use multiple formats to convey a message. Consider advertising as a means of wanting to convey message and influence your actions. aSome software companies create beta communities, Think of the adverts that have sound, visuals, or release beta versions as a means of generating logic and evoke feelings… Is this something to interest in a product, testing its market viability, consider when creating vision?and gaining insights and feedback from early adopter consumers. A comprehensive explanation and guide to this approach is provided in the book The Lean Start-up by Eric Ries.Another, less used source of customer feedback is Customer Services (CS). I think that Customer Services is an underutilised source of extremely valuable information. When I was COO of a small
  5. 5. Agile:MK Journal December 2012RoadmapA Roadmap encapsulates the ‘How?’ of the Vision – • Working software is the primary measure it is a means of portraying how we move from the of progress.current state to the vision state. There are many ways of portraying a roadmap with an example shown here: • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. The discussion then moved to the risks associated with the public release of roadmap information. Particularly in product development, the expectation from the industry itself, the market, and investors or shareholders, is that there is a clear longer-term plan for the development of the product. The value in publicising a roadmap is: • establishing a sense of longevity and strategy Roadmaps in an agile context are often a source of for the productfrustration and potential conflict, where potentially no conflict exists. A roadmap is a long-term plan of • informing public influencers and market intent, in an agile context the Roadmap needs to analysts of intentions and investment levels maintain its overall direction and intent, but have the for the productflexibility to achieve the objective via different routes. • Informing investors, existing VC, shareholders If you are driving from London to Inverness, you or prospective investors of the viability and might plan to use the M40, M6, M74 and then up to potential market growth and returns of the M90 and A9. However, if there are accidents, road the productclosures, toilet breaks or break-downs, you’d assesswhere you are, how far there is to go, what needs • providing customers with a view of why the to change to achieve the goal and adapt your plan product is worth purchasing or continuing accordingly maintaining the same overall long-term to upgradegoal of getting to Inverness. A roadmap should have The risks to publicising a roadmap are:the same adaptability. • Competitor response to your long-term viewIn fact, in creating a roadmap the following agile principles would be useful to keep in mind: • Potentially committing yourself in terms of investment levels to a long-term plan • Our highest priority is to satisfy the customer through early and continuous delivery • Committing yourself in terms of feature of valuable software. development to a long-term plan that you might want to adapt/change/amend in • Welcome changing requirements, even late in response to competitor, market or other development. Agile processes harness change external and internal factors for the customer’s competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  6. 6. Agile:MK JournalProduct Backlog The UserA Product Backlog is a prioritised list of requirements. Each story starts with “As a [user of the solution]…” Typically, requirements are written in the ‘story’ format this stems for the older disciplines of user-centred based on the needs of a user of the future solution. design. By thinking about who the various users of The nature of a Product Backlog is to be flexible and the solution are, the Product Owner is able to constantly changing, the Product Backlog helps to empathise with the goals of a user, more clearly support the agile principle of: distinguish them, and prioritise them for delivery.Welcoming changing requirements, even late in development. Agile processes harness change for The Requirementthe customer’s competitive advantage. Each story continues “As a [user of the solution], I In this way the direction and features of the solution want ….” The “I want…” part of the story should can meander, shift and change based on extracting the define a user goal. Having previously established highest return on investment rather than completing the users of the solution, each story defines each a project to scope, budget and time. The purpose of of the individual goals of each development is not to complete projects to time, scope and budget but to provide business benefit to the company - most commonly as a returnon investment. Each story can be reprioritised at Why?will, unless it is in the process of being developed i.e. The story then describes why the goal exists, prior to a sprint or iteration. what is the driver behind the goal i.e. the benefits In order to be able to re-prioritise at will, and still of delivering this requirement to the user.maintain high levels of productivity, stories “As a [user of the solution], I want… [user specific typically follow an established format and process goal], so that [I can reap these benefits]for articulation. And the value to the [company] is… This final part of the story is rarely used at a granular level, but Stories for Epics and Releases relates to the quantifiable business case for a feature or release of software. Acceptance Criteria Each story then has associated acceptance criteria. These are the means by which the Product Owner knows the requested story features have been delivered. Another way to think of this is, “if asked whether the requirements of a story have been met by the solution, what would you test for?” I have found this to be a very good way of working, as it gets the Product Owner to define ‘tests’ as acceptance criteria. i.e. Test that… this part works, Test that… another part works etc.Stories are a place-holder for a conversation. The intended nature of stories is for them to be evolutionary, to evolve as the project evolves, and then during an iteration or sprint they morph into software. Stories often start out as items on a wish list, and as the project grows so the stories evolve into an established structure which is outlined here.
  7. 7. Agile:MK JournalInvestIn order for these stories to be re-prioritised, evolvingand meet the principle of:Welcoming changing requirements, even late in development, Agile processes harness change for the customer’s competitive advantage.It is established practice to ensure that all stories conform to the INVEST rules:Independent: One of the characteristics of Agile Methodologies such as Scrum or XP is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, agood idea might be to combine them into a single During our discussion we discussed the ‘sized user story. appropriately’ rule in more detail. For a Product Backlog, the goal is to provide more granularity Negotiable: The only thing that is fixed and set in and smaller stories in a just-in-time mindset so stone in an agile project is an iteration backlog (and, that if the backlog is reprioritized there is little even then, it can be broken). While the story lies waste in terms of the time and energy taken to in the product backlog, it can be rewritten or even define the stories. This goal translates into the discarded, depending on business, market, technical higher priority items in a backlog being broken or any other type of requirement by team members. down into smaller pieces, whilst the lower Valuable: The focus here is to bring actual project- priority items remain somewhat vague and related value to the end-user. Coming up with large in size until they are closer to the top and technical stories that are really fun to code but therefore closer to being worked by the team.bring no value to the end-user beats one of the We also discussed the role of Product Owner Agile Principles, which is to continuously deliver and the various models and patterns for ensuring valuable software there is strong business domain knowledge within Estimable: If a user story size cannot be estimated, the team and the direction of the software it will never be planned, tasked, and, thus, become development is defined by the business. We came part of an iteration. So there’s actually no point to a consensus that each company, organization, in keeping this kind of user story in the Product programme or project is unique, and that regardless Backlog at all. Most of the time, estimation of who and how you structure your product cannot be executed due to the lack of supporting ownership capability the goal is “to create a rapid information either in the story description itself decision-making capability to enable the ROI to or directly from the Product Owner. be met”Sized Appropriately: Try to keep your user story sizes to typically a few person-days and at most a few person-weeks. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even “epic” and broken down into smaller user stories. There’s no problem in starting with epic stories, as long as they are broken down when the time to place them in an iteration backlog becomes closer.Testable: Bear in mind that a story should only be considered DONE, among other things, if it was tested successfully.
  8. 8. Agile:MK JournalStory MapsWhen faced with a Product Backlog of 3000 Scrum utilises burn-downs to forecast delivery requirements, it can be a little daunting without dates. Burn-downs provide a view of the outstandingclustering and organising the information. Story amount of work or features to be completed (shown maps are a simple means to showing users, major in green). By using previous performance, the burn-features, and progress of the project. We use the down provides an empirical forecast of completionterm Epic to represent a very large story or an (amber dotted line).entire feature of a solution. The map helps simplify the backlog, where each Epic represents a large For the Product Backlog there is a Product Burn-downnumber of stories. By using colour we can show which provides a real-time forecast of when the currentcompleted features in green, in progress as amber scope of features will be complete. The unit of measureand red as work that has not started. There are used for forecasting is the story point. Story points aredifferent styles of story maps (such as showing nebulous units of time (NUTS), they are an indicator ofEpics and their smaller stories), all of which the size and complexity of a feature or story – NOT anhave the same goal of simplifying the structure indicator of time or effort.and progress of a Product Backlog for ease of understanding and communication. There are many arguments about the validity of story points as a measure and forecasting tool. One of the problems commonly faced when agile Story Points & Sampling has been adopted as a process, but not its principles, is the desire from senior managers for a consistentOur discussion moved on to the more contentious measure of points. To solve this problem, a commonarea of story pointing. In an agile mind-set, there pattern s to adopt a sampling process, whereby iis a fundamental belief or tenet that software there are a small number of ‘example stories’ which development is a complex process, with variable are used to calibrate story points.inputs, non-standard work & processes, which results in variable/non-predictive output. This If you are not being pressed for a consistent unit makes forecasting accurate outcomes for time of measurement I would suggest not using this and cost very difficult, and whilst the activity of process, but it can be useful for emphasising planning has high value, the plan itself is out of increases in velocity because although the team date before the ink dries. might have improved and matured and therefore stories can be completed quicker, without a “In preparing for battle I have always found that consistent sizing approach these improvements plans are useless, but planning is indispensable.” will become invisible to the rest of the business. Dwight D. Eisenhower
  9. 9. Agile:MK JournalVelocity, Rapid Feedback & Splitting StoriesBy measuring the number of story points completed In order to live by these principles, software features within an iteration or sprint, we are able to calculate a are broken down into their smallest elements velocity (velocity = story points/iteration). Personally whilst maintaining their integrity as stories by being I calculate my expected velocity based on a 3-sprint Independent, Negotiable, Valuable, Estimable, Sizedaverage. Correctly and Testable.The Scrum approach to requirements articulation Clearly if stories are not split-down to be small through the use of stories is underpinned by the enough the team will not be able to produce following agile principles: potentially shippable product every sprint. Once a team has achieved this level of granularity • Our highest priority is to satisfy the customer there is a further improvement – to build pieces through early and continuous delivery of working software every couple of days. Many of valuable software. mature teams have reached this level of operation where stories are broken down, and the team’s • Welcome changing requirements, even late in agile process adoption is strong enough to enable development. Agile processes harness change software creation end to end within 2-3 days. The for the customer’s competitive advantage. ultimate point of evolution of this approach is known • Deliver working software frequently, from a as Continuous Delivery but this capability has many couple of weeks to a couple of months, with other process and technology dependencies before a preference to the shorter timescale. it becomes a reality.
  10. 10. ripplerock offers a set of services and tools that enable our customersto dramatically improve their software development capabilityRippleRock formed in 2009 with the mission to assist customers drive dramatic improvements in their software developmentcapability. We apply our expertise across the full lifecycle; facilitating organisational transformation to enable Agile practices,all the way down to improving engineering practices within the teams.The team at RippleRock have a strong track record in the Agile space, some of this through experience gained while at thecentre of Conchango’s Agile Practice and Scrum for Team System tools group. As a specialist in this area we are able to offeraccess to the most experienced Agile coaches, trainers and consultants with the particular mix of skills required to work withpeople, process, organisations and tools.Ripple Rock Ltd is registered in England and Wales No. 0708916Ripple Rock LLC is registered in the United States of America. No. 27-1180168