 |  |  |  |  |  |
Agile Whitepapers
| Success Architechs C o n s u l t i n g G r o u p "Building Project Success Through Managing Requirements" |
(SA)
2
Requirements Planning for Agile Development Projects
© 2008 by Jacqueline K. Sanders
This article will share with you when and how Business Analysts do requirements planning. and how they adapt their business analysis skills, techniques, and experience to benefit an Agile project.
To set the stage, I will start by describing a few common characteristics about Agile. Agile development
is being referred in this article as a framework for software development that encompasses building
and deploying in short iterations throughout the life-cycle of the project. There are many permutations
of the Agile development methods. Iterations typically range from one to four weeks, each containing
planning, requirements analysis, design, coding, testing and deployment. The project team is typically
co-located with developers, testers, a subject matter expert, an iteration manager, and last but not
least, someone who has the responsibility of the requirements, the Business Analyst, (BA) . The caveat
is that the person who plays the BA role may not necessarily have the title of Business Analyst. They
may even play multiple roles in which requirements engineering is not their primary role. In some Agile
implementations, the project team members are all considered “generalists” with no specific titles. For
purposes of this article, the role that manages the requirements on an Agile project will hereafter be
referred to as the BA.
The principles behind Agile are attributed to the Agile Manifesto. The Agile Manifesto was created by a
group of 17 people, who were looking for a “light-weight software development methodology” that is
more people/developer centric.
Some of the principles behind the Agile Manifesto are:
Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Even late changes in requirements are welcomed
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Self-organizing teams
Regular adaptation to changing circumstances
Simplicity
The publishing of the manifesto spawned a movement in the software industry that is becoming
popular, intriguing, and controversial all at the same time. Part of the controversy is due to the fact
that the Agile development was not meant to be a plan driven or structured methodology, like its earlier
counterparts (i.e. Waterfall, RUP). However, there are many books and training courses that dictate
specific ways Agile should be implemented.
Since Agile is not plan driven, you might think this will be a rather short article since the topic is about
requirements planning. But This article gives you an insider's perspective based on real world
implementations not just an academic point of view. The intent is to focus on two of the most
controversial components around Agile, planning and requirements. This begs the question, “Can
planning and requirements fit into the informal Agile world and still be effective?” Some BA’s, like me,
that have successfully adapted to Agile, will say "yes".
The biggest thing that traditional BAs may resist about Agile is the lack of prescribed deliverables and
techniques. BAs’ on Agile projects should be prepared to let go of their formal requirements documents
and move toward less formal delivery methods. The requirements blueprint may be scribbled informally
on an erasable, portable white board.
The BA working on an Agile project is ultimately responsible for ensuring that the requirements core
components are defined. The BA still has to perform due diligence on the requirements yet with Agile
this is often in a covert or stealth mode that begins prior to Iteration 1.In a less publicized iteration,
called Iteration O, we quietly plan. The BA accepts that once Iteration 1 kicks off, on a daily basis they
will have to adapt to the ever changing demands of the Agile development environment. Iteration 0 is
the only time the Business Analyst will be proactive and not be distracted by the day to day adaptive
nature of Agile. During subsequent iterations, they need to think on their feet and react to the daily
circumstances.
The rest of this article focuses on the requirements and planning task that are a part of Iteration 0 and
the associated business analysis tasks listed for Iteration 0 in (Figure 1) below.
How the BA role supports Agile iterations
Iteration 0 planning has been vital for me on new development projects whereas it is a judgment call
depending on complexity whether Iteration 0 planning is needed for maintenance releases. New
development projects contain many features and functions spread across many Agile iterations,
Iteration 0 planning insures that those pieces create an integrated end product with little to no rework.
One project I worked took place in 28 weekly iterations over a 7 month period. The three months prior
to the first iteration were used to do the scoping and planning. The five tasks below describe the
requirements planning work done in Iteration 0:
Stakeholder Analysis
Even though Agile is known for having customers assigned to work on the project team, the reality is
that often there are multiple stakeholders affected by a project in different degrees. Not every
stakeholder needs to be assigned full time to the project but they do need to be consulted as needed.
The BA needs to do a full assessment of anyone that might be impacted. The information gathered
during stakeholder analysis provides the BA the knowledge to know when to involve or consult a
particular stakeholder in the future iterations. The primary, assigned stakeholder may be able to make
the majority of decisions but it is up to the BA to represent or gain consensus in those areas that
impact several stakeholders. In Iteration 0 the BA is trying to preplan the stakeholder involvement, so
when there are impromptu meetings during the development iterations, they can readily know who to
contact.
Scope Definition
The Business Analyst is initially provided a high level scope statement. The BA uses Iteration 0 to
refine and finalize the scope. Part of finalizing the scope means to validate the purpose of the project,
finalize quantifiable objectives, and define what is the problem to be solved or the opportunity being
pursued. Also during scoping, consensus on the project approach was reached. In my project, there
were several different approaches, information was gathered on the pros and cons for each. There
were several facilitated sessions, stakeholder meetings and presentations focused on scope in
Iteration 0. A well defined scope is very significant on a Agile project because there is a great deal of
flexibility and many interpretations that come about as the requirements evolve throughout the project.
As the informal requirements discussions are taking place the BA needs to insure the end product will
still meet the objectives of the project sponsor. The scope provides the boundary that ensures that
discussions and decisions made during the development iterations are kept in context and focused.
Solution Decomposition
As soon as the BA has defined the scope of the solution, they work with the Software Designers and/or
Architects to draw an outline of the design. On Agile projects the requirements and design tasks are
often blended together. As the BA is revealing scope, the designers are up on a white board creating
a framework of ideas for the solution.
The design framework has to be a flexible overview of the solution since the detail requirements are yet
to be defined. It’s necessary to create an overview of the solution so that there is a “Big Picture” of the
end product. The “Big Picture” allows the BA to work with the project team to plan how to break the
work into components that fit into the iteration timeframe. The output of each of those iterations must
fit back together at the end of the development iterations in a cohesive manner. Making sure those
pieces fit back together and avoiding rework justifies the purpose of the planning effort that takes place
in Iteration 0.
Breaking the overall solution into small pieces requires a lot of negotiation, justification and sometimes
frustration. The BA spend lots of time with the Design and System Architect identifying design risk,
priorities and consequences as a part of Solution Decomposition. Because these discussions are
usually very technical, the customers do not participate. In these meetings the BA answers various
questions related to risk, priorities, and assumptions that need to be considered.
Informal Models
On this Agile project where new development was occurring, changes were required in the data,
process, business rules, and user interfaces. Although Agile revolves around verbal communications,
we often validate our words with pictures. Starting in Iteration O, the complex verbal discussions were
typically supplemented by drawings on a white board. One person might start by illustrating what they
were trying to communicate, then another person would add to the initial drawing and before you know
it everyone was standing at the white board with a different color marker adding and modifying the
drawing. A BA would recognize that these drawings were informal variations on workflow diagrams,
logic maps, data relationship models, and decomposition diagrams. The collaborative drawing often
stayed up on the white board in the co-located area throughout the development iterations as a
reference. In later iterations, there were new discussions that would result in revisiting and changing
the drawing which is part of the flexibility of using the white board and is consistent with the Agile
concept.
The BA add value to the many impromptu discussions because of their knowledge and experience on
facilitation and effective communications techniques. In Iteration 0 the BA can identify high risk and
high impact issues which will benefit from an informal facilitated discussions in a later iteration. During
later iterations the BA can identify and perhaps provide an informal data or process diagram which
would help promote the disucssion.
Reference Models
During Iteration 0 the BAs still create their various formal models but use them as reference material
and as auxiliary documentation. Some BAs may be reluctant to admit this. The models serve the
purpose of identifying gaps as well as overlap in the functions. In this scenario the models are tools
and not for the intent of presentation or to be part of a package of documentation. When developers
ask an impromptu question, the BA will refer to these models and diagrams to insure that the answer is
leading the developers to a cohesive end product. The traditional models help the BA anticipate the
various questions she will be asked and the answers she will be expected to provide.
Conclusion
What makes planning unique for Agile projects is that during the development iterations the BA is work
is impromptu and at a fast pace. The diagram above shows you what occurs in the remaining iterations
which we will explore in future white papers. But as you can see, the planning work that takes place in
Iteration 0 helps the BA be prepared for whatever unscripted questions will come there way in latter
iterations. The BA is the gatekeeper for the comprehensive informal and high level requirements.
Although in Agile much of the requirements work is not planned, it can be expected. A seasoned BA
can predict and anticipate what type of questions and communication will be necessary to facilitate
discovering the right solution. BA’s have to learn how to apply their skills and techniques but in a very
agile way.
© 2008 by Jacqueline K. Sanders
This article will share with you when and how Business Analysts do requirements planning. and how they adapt their business analysis skills, techniques, and experience to benefit an Agile project.
To set the stage, I will start by describing a few common characteristics about Agile. Agile development
is being referred in this article as a framework for software development that encompasses building
and deploying in short iterations throughout the life-cycle of the project. There are many permutations
of the Agile development methods. Iterations typically range from one to four weeks, each containing
planning, requirements analysis, design, coding, testing and deployment. The project team is typically
co-located with developers, testers, a subject matter expert, an iteration manager, and last but not
least, someone who has the responsibility of the requirements, the Business Analyst, (BA) . The caveat
is that the person who plays the BA role may not necessarily have the title of Business Analyst. They
may even play multiple roles in which requirements engineering is not their primary role. In some Agile
implementations, the project team members are all considered “generalists” with no specific titles. For
purposes of this article, the role that manages the requirements on an Agile project will hereafter be
referred to as the BA.
The principles behind Agile are attributed to the Agile Manifesto. The Agile Manifesto was created by a
group of 17 people, who were looking for a “light-weight software development methodology” that is
more people/developer centric.
Some of the principles behind the Agile Manifesto are:
Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Even late changes in requirements are welcomed
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Self-organizing teams
Regular adaptation to changing circumstances
Simplicity
The publishing of the manifesto spawned a movement in the software industry that is becoming
popular, intriguing, and controversial all at the same time. Part of the controversy is due to the fact
that the Agile development was not meant to be a plan driven or structured methodology, like its earlier
counterparts (i.e. Waterfall, RUP). However, there are many books and training courses that dictate
specific ways Agile should be implemented.
Since Agile is not plan driven, you might think this will be a rather short article since the topic is about
requirements planning. But This article gives you an insider's perspective based on real world
implementations not just an academic point of view. The intent is to focus on two of the most
controversial components around Agile, planning and requirements. This begs the question, “Can
planning and requirements fit into the informal Agile world and still be effective?” Some BA’s, like me,
that have successfully adapted to Agile, will say "yes".
The biggest thing that traditional BAs may resist about Agile is the lack of prescribed deliverables and
techniques. BAs’ on Agile projects should be prepared to let go of their formal requirements documents
and move toward less formal delivery methods. The requirements blueprint may be scribbled informally
on an erasable, portable white board.
The BA working on an Agile project is ultimately responsible for ensuring that the requirements core
components are defined. The BA still has to perform due diligence on the requirements yet with Agile
this is often in a covert or stealth mode that begins prior to Iteration 1.In a less publicized iteration,
called Iteration O, we quietly plan. The BA accepts that once Iteration 1 kicks off, on a daily basis they
will have to adapt to the ever changing demands of the Agile development environment. Iteration 0 is
the only time the Business Analyst will be proactive and not be distracted by the day to day adaptive
nature of Agile. During subsequent iterations, they need to think on their feet and react to the daily
circumstances.
The rest of this article focuses on the requirements and planning task that are a part of Iteration 0 and
the associated business analysis tasks listed for Iteration 0 in (Figure 1) below.
How the BA role supports Agile iterations
Iteration 0 planning has been vital for me on new development projects whereas it is a judgment call
depending on complexity whether Iteration 0 planning is needed for maintenance releases. New
development projects contain many features and functions spread across many Agile iterations,
Iteration 0 planning insures that those pieces create an integrated end product with little to no rework.
One project I worked took place in 28 weekly iterations over a 7 month period. The three months prior
to the first iteration were used to do the scoping and planning. The five tasks below describe the
requirements planning work done in Iteration 0:
Stakeholder Analysis
Even though Agile is known for having customers assigned to work on the project team, the reality is
that often there are multiple stakeholders affected by a project in different degrees. Not every
stakeholder needs to be assigned full time to the project but they do need to be consulted as needed.
The BA needs to do a full assessment of anyone that might be impacted. The information gathered
during stakeholder analysis provides the BA the knowledge to know when to involve or consult a
particular stakeholder in the future iterations. The primary, assigned stakeholder may be able to make
the majority of decisions but it is up to the BA to represent or gain consensus in those areas that
impact several stakeholders. In Iteration 0 the BA is trying to preplan the stakeholder involvement, so
when there are impromptu meetings during the development iterations, they can readily know who to
contact.
Scope Definition
The Business Analyst is initially provided a high level scope statement. The BA uses Iteration 0 to
refine and finalize the scope. Part of finalizing the scope means to validate the purpose of the project,
finalize quantifiable objectives, and define what is the problem to be solved or the opportunity being
pursued. Also during scoping, consensus on the project approach was reached. In my project, there
were several different approaches, information was gathered on the pros and cons for each. There
were several facilitated sessions, stakeholder meetings and presentations focused on scope in
Iteration 0. A well defined scope is very significant on a Agile project because there is a great deal of
flexibility and many interpretations that come about as the requirements evolve throughout the project.
As the informal requirements discussions are taking place the BA needs to insure the end product will
still meet the objectives of the project sponsor. The scope provides the boundary that ensures that
discussions and decisions made during the development iterations are kept in context and focused.
Solution Decomposition
As soon as the BA has defined the scope of the solution, they work with the Software Designers and/or
Architects to draw an outline of the design. On Agile projects the requirements and design tasks are
often blended together. As the BA is revealing scope, the designers are up on a white board creating
a framework of ideas for the solution.
The design framework has to be a flexible overview of the solution since the detail requirements are yet
to be defined. It’s necessary to create an overview of the solution so that there is a “Big Picture” of the
end product. The “Big Picture” allows the BA to work with the project team to plan how to break the
work into components that fit into the iteration timeframe. The output of each of those iterations must
fit back together at the end of the development iterations in a cohesive manner. Making sure those
pieces fit back together and avoiding rework justifies the purpose of the planning effort that takes place
in Iteration 0.
Breaking the overall solution into small pieces requires a lot of negotiation, justification and sometimes
frustration. The BA spend lots of time with the Design and System Architect identifying design risk,
priorities and consequences as a part of Solution Decomposition. Because these discussions are
usually very technical, the customers do not participate. In these meetings the BA answers various
questions related to risk, priorities, and assumptions that need to be considered.
Informal Models
On this Agile project where new development was occurring, changes were required in the data,
process, business rules, and user interfaces. Although Agile revolves around verbal communications,
we often validate our words with pictures. Starting in Iteration O, the complex verbal discussions were
typically supplemented by drawings on a white board. One person might start by illustrating what they
were trying to communicate, then another person would add to the initial drawing and before you know
it everyone was standing at the white board with a different color marker adding and modifying the
drawing. A BA would recognize that these drawings were informal variations on workflow diagrams,
logic maps, data relationship models, and decomposition diagrams. The collaborative drawing often
stayed up on the white board in the co-located area throughout the development iterations as a
reference. In later iterations, there were new discussions that would result in revisiting and changing
the drawing which is part of the flexibility of using the white board and is consistent with the Agile
concept.
The BA add value to the many impromptu discussions because of their knowledge and experience on
facilitation and effective communications techniques. In Iteration 0 the BA can identify high risk and
high impact issues which will benefit from an informal facilitated discussions in a later iteration. During
later iterations the BA can identify and perhaps provide an informal data or process diagram which
would help promote the disucssion.
Reference Models
During Iteration 0 the BAs still create their various formal models but use them as reference material
and as auxiliary documentation. Some BAs may be reluctant to admit this. The models serve the
purpose of identifying gaps as well as overlap in the functions. In this scenario the models are tools
and not for the intent of presentation or to be part of a package of documentation. When developers
ask an impromptu question, the BA will refer to these models and diagrams to insure that the answer is
leading the developers to a cohesive end product. The traditional models help the BA anticipate the
various questions she will be asked and the answers she will be expected to provide.
Conclusion
What makes planning unique for Agile projects is that during the development iterations the BA is work
is impromptu and at a fast pace. The diagram above shows you what occurs in the remaining iterations
which we will explore in future white papers. But as you can see, the planning work that takes place in
Iteration 0 helps the BA be prepared for whatever unscripted questions will come there way in latter
iterations. The BA is the gatekeeper for the comprehensive informal and high level requirements.
Although in Agile much of the requirements work is not planned, it can be expected. A seasoned BA
can predict and anticipate what type of questions and communication will be necessary to facilitate
discovering the right solution. BA’s have to learn how to apply their skills and techniques but in a very
agile way.
