You are on page 1of 3

rolling wave planning:

You typically start with a high-level plan that is sufficient for defining at le
ast the vision, scope, and
objectives of the project to whatever level of detail is needed at that point to
support whatever level
of planning and estimation is required for the project.
The details of the plan and the requirements are further elaborated as the proje
ct progresses.
Planning strategies
waterfall vs agile
You should always fit the methodology to the project based on the characteristic
s of the project and
other factors such as the training and capabilities of the project team
One of the biggest factors that influences the selection of an approach is the l
evel of uncertainty in the project.
It is not a black-and-white decision to be totally plan-driven or totally adapti
ve. There are plenty of alternatives between those two extremes.
a technique called a spike is often used in an agile project to resolve uncertai
nty.
A spike is a special kind of iteration that is used to do research, possibly pro
totype a solution, and/or
evaluate alternative approaches for resolving uncertainty associated with develo
ping a solution.
progressive elaboration: Requirements should only be defined to the extent neede
d to support whatever
decisions or action is required at that particular point in time. project level> release level -> sprint level
Value-based functional decomposition
start with a vision statement that clearly defines the business value that the s
olution will provide,
A vision statement should be short and succinct.
example of a format:
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
Once a high-level vision statement has been defined use functional decomposition
to break down that vision statement into the functionality that will be needed
to achieve that overall vision. Functional decomposition becomes particularly im
portant on large projects where there could be hundreds of user stories. It prov
ides a hierarchical approach for organizing and prioritizing requirements.
business analyst primary functions in agile:
-Analyze a broadly defined area and use functional decomposition to define highlevel epics and
stories to create a well-organized, value-driven framework to provide the requir
ed business value
in the product backlog.
-Write individual stories that are very clear and concise and are easy to unders
tand and implement
by the project team.
-Identify related user stories and epics, grouping them into a logical structure

as necessary and
documenting the interrelationship and associated business process flows as neces
sary.
-Integrate the needs of various stakeholders to produce an overall solution.
a very important principle in agile is simplicity and limiting a solution to wha
t is just barely good enough to solve the problem. There is an optimum point, and
beyond that point, adding additional features has diminishing value. It requires
close collaboration with the users to find where that optimum point
is. A good technique is to start with the simplest and most basic solution possi
ble and then add to it incrementally and iteratively only to the extent that it
adds value to the user.
Another very good technique in developing requirements for agile projects is to
differentiate wants from needs.
Wants tend to be associated with a solution that a client envisions.
Needs tend to be associated with the problem.
The five whys method is a good approach for digging into a customer need to get
to the root of the problem. The idea is that by progressively asking why over-andover again, you eventually get to the root cause of the problem.
Another very good technique for prioritizing requirements is called MoSCoW, must
have, should have, could have, won't have
Organizing the project requirements around specific users and their needs puts m
ore focus on really understanding the value that the project provides and who th
e recipient of that value is. To facilitate that process, it is useful to identi
fy user personas as specifically as possible so that the project team can target
their development efforts at the needs of those specific users. A user persona
could be a specific category of user or it could even be a specific user, but in
either case, it is useful to model that users personality and specific interests
as a hypothetical user persona. A user persona helps the team visualize that us
er and focus its efforts around the users needs.
User stories
User stories are a succinct way of defining requirements in agile. Telling user
stories is a way of simplifying
the definition of the requirements in a language that can be easily understood b
y both developers
and users. It breaks the requirements into small chunks of functionality that ca
n be built incrementally.
User stories follow the general format shown below:
As a <role> I want <to be able to do something> so that <benefit>
Independent: Stories should be as independent as possible so that they can be work
ed on in any
order. That will simplify the flow of stories through development and avoid bott
lenecks that can be
caused by having too many dependencies among stories.
Negotiable: Stories should be negotiablea story is a placeholder for conversation,
and some dialog
is expected to take place to explore trade-offs associated with developing the s
tory as efficiently and
as effectively as possible.

Valuable: Stories should be valuablethe value that a story is intended to produce s


hould be
clearly-defined so that the product owner can make an objective evaluation of th
e level of effort
required versus the value to be gained from the story.
EstimableEstimable is the next important characteristic. A story needs to be suffic
iently defined
so that the team can develop a high-level estimate of the effort required for th
e story in story
points.
SmallStories should be relatively small so that functionality can be developed and
tested as incrementally
as possible. Breaking the work into small chunks allows it to flow much more smo
othly and
allows the work to be distributed more evenly among the team while large efforts
can easily lead to
bottlenecks and inefficiencies in distributing work among the team.
Testable: Finally, stories should be testable to determine if they have successful
ly fulfilled the
value proposition that they are intended to fulfill. Its a good practice with agi
le stories to write
acceptance test criteria, along with the stories to define the tests that they n
eed to fulfill. The test
criteria essentially take the place of more detailed specifications for what the
story must do.
Epics
An epic is basically a very large user story. An epic serves the purpose of asso
ciating related individual
user stories with a higher-level purpose that they are collectively intended to
fulfill, but an epic is normally
too large for the project team to work on directly without breaking it down into
individual user
stories. Its a useful technique on large, complex projects for organizing user st
ories into some kind
of structure so that the interrelationship of user stories is well-understood. T
he following shows an
example of a large epic and how it can be broken down into smaller stories.
The product backlog consists of user stories, and it is dynamic. The user storie
s are continuously groomed and prioritized over the course of a project. It is
essentially a queue of work to be done.
The principles of rolling-wave planning are used in product backlog grooming and
items start out at the bottom of the backlog
as being very roughly defined and the stories are progressively groomed as they mo
ve closer

You might also like