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 met…

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. 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
http://tinyurl.com/ 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
www.endjin.com

3. Agile:MK Journal
Writing Good Requirements
How Do You Recognise
Good Requirements Definition? People
We 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 business
had 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 and
requirements 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 been
met… 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. Agile:MK Journal
a 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 Vision
used 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 attempt
MVT 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.
a
Some 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. Agile:MK Journal December 2012
Roadmap
A 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 product
frustration 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 product
flexibility 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 product
closures, toilet breaks or break-downs, you’d assess
where 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 upgrade
goal of getting to Inverness. A roadmap should have
The risks to publicising a roadmap are:
the same adaptability.
• Competitor response to your long-term view
In 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. Agile:MK Journal
Product Backlog The User
A 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 Requirement
the 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 user.
software development is not to complete projects
to time, scope and budget but to provide business
benefit to the company - most commonly as a return
on 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. Agile:MK Journal
Invest
In order for these stories to be re-prioritised, evolving
and 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, a
good 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. Agile:MK Journal
Story Maps
When 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 outstanding
clustering 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 completion
term 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-down
number of stories. By using colour we can show which provides a real-time forecast of when the current
completed features in green, in progress as amber scope of features will be complete. The unit of measure
and red as work that has not started. There are used for forecasting is the story point. Story points are
different styles of story maps (such as showing nebulous units of time (NUTS), they are an indicator of
Epics and their smaller stories), all of which the size and complexity of a feature or story – NOT an
have 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 consistent
Our discussion moved on to the more contentious
measure of points. To solve this problem, a common
area of story pointing. In an agile mind-set, there
pattern s to adopt a sampling process, whereby
i
is 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. Agile:MK Journal
Velocity, Rapid
Feedback & Splitting Stories
By 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, Sized
average. 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. ripplerock offers a set of services and tools that enable our customers
to dramatically improve their software development capability
RippleRock formed in 2009 with the mission to assist customers drive dramatic improvements in their software development
capability. 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 the
centre of Conchango’s Agile Practice and Scrum for Team System tools group. As a specialist in this area we are able to offer
access to the most experienced Agile coaches, trainers and consultants with the particular mix of skills required to work with
people, process, organisations and tools.
Ripple Rock Ltd is registered in England and Wales No. 0708916
Ripple Rock LLC is registered in the United States of America. No. 27-1180168 www.ripple-rock.com