This lightly edited excerpt from Beyond Requirements:Analysis with an Agile Mindset describes a typical approach to analysis in software product development where teams exhibit an agile mindset. It places into context most of the techniques described in the technique briefs on the site. This approach to analysis happens in four steps, illustrated in the figure below:
- What is the need?
- What are some possible solutions?
- What should we do next?
- What are the details of this part?
These steps do not necessarily happen in quick succession. Often you return to some steps again and again as you develop a deeper understanding of your initiative.
One of the primary reasons for breaking this approach into steps is to remind your team to evaluate your initiative on a regular basis and determine what to do next.
After each step you should ask whether you should continue working on the initiative as it is currently envisioned, change the direction of the initiative, or stop the initiative. This is the “Commit to, Transform, or Kill” question for portfolio items that Johanna Rothman describes in her book Manage Your Project Portfolio [Affiliate Link].
Let’s take a closer look at how this actually flows, what techniques are helpful, and what kind of evaluation needs to occur at each step.
What Is the Need?
In this step, your team seeks to understand your stakeholders, their needs, and which of those needs, if any, are worth satisfying.
In other words, what problem are you trying to solve or what opportunity are you trying to exploit?
This evaluation has two aspects: stating the need, and ensuring that everyone involved has a shared understanding of the desired outcome.
Techniques your team can use for identifying the need and building a shared understanding include the problem statement and the internal product opportunity assessment. When your team takes a collaborative approach to these techniques, you not only describe the need but also builds a shared understanding.
You may also want to clarify goals and objectives, which helps your team answer the question “Do we know what success looks like and how to measure it?” In addition, decision filters give the team a way to stay on track and tie the effort back to strategic direction or the objectives themselves.
These techniques are best applied when an effort is getting off the ground, but it never hurts to revisit them when new team members come aboard or the team senses that conditions have changed in a way that may change the need itself.
During this step your team answers the question “Is this need worth satisfying?” This may be better stated as “Is this need a big deal regardless of the time and money we need to spend to satisfy it?”
If so, move forward. If not, stop right here.
What Are Some Possible Solutions?
Once you understand the need you’re trying to satisfy, it’s generally a good idea to come up with multiple possible solutions. Identifying a set of options improves the chances of ident
It’s rarely a good idea to assume that there is only one solution for a given need. Identifying multiple possible solutions is important, but it is helpful to note the differences among those options and understand ways of identifying and assessing them.
If you find yourself in a situation where you have a need to satisfy and you’ve defined a goal to know when you have satisfied it but you don’t have a specific solution in mind, you have a great deal of flexibility. Impact mapping can be very helpful in identifying what solution(s) you should work on and in what order. This is especially true when the solution depends on altering stakeholder behaviors.
In other cases, you know the general solution, but you could take different paths to get there. These situations are more a matter of implementation decisions: build versus buy, which packages to purchase, and so on. If you are facing an effort with uncertain implementation, an analysis similar to impact mapping may have been done at a more organization-wide level to determine whether the goals of that particular effort were important to address for the purposes of a greater strategic goal. So, either you identify a possible solution and then decide on the desired implementation, or you focus solely on the implementation.
Story mapping can also be helpful to supply some context for the various things that need to be done and when they should occur. It also provides a starting point for the next step in analysis.
When your team is trying to figure out the possible solutions, or lands on a solution you would like to explore further, there’s a good chance that you will perform some collaborative modeling to understand things better. Common models used at this point include a context diagram, process flows, business domain models, wireframes, and storyboards.
During this step, your team may identify features as placeholders for the big changes necessary to implement the eventual solution.
Your team will ask, “Is this need worth satisfying with this solution?” about every potential solution, pushing aside solutions that do not make sense.
What Should We Do Next?
This step is where your team gets down to deciding which solution, or part of a solution, to deliver to stakeholders next. You may reference existing models and create new models to start pinpointing the specifics of the solution. Your team will use current-state and future-state models to identify specific changes that are necessary, and they will start breaking the features already identified into more granular user stories for planning purposes.
Your team usually does this during release planning which results in a subset of work that your team focuses on for the next delivery. You use decision filters to determine which user stories should be included in the release backlog. Your team revisits the backlog on a regular basis to incorporate revised understanding of the need and how you believe the solution is working to solve it.
In this step your team compares the solutions that made the cut, with special attention to the cost effectiveness of specific solutions. You also evaluate how well the identified solution delivers the desired outcome.
What Are the Details of This Part (i.e.,Telling the Story)?
Once your team selects the next part of the solution you are going to deliver, you begin the work to further understand and describe the solution for purposes of delivery. User stories are typically best described through the use of models, examples, and acceptance criteria. The nature of each user story and your team’s definition of ready dictate how extensively your team uses each technique.
When completed, models, examples, and acceptance criteria should convey all the information the team has agreed they need in order to begin delivery, as detailed in the definition of ready. Progress toward the definition of ready may be tracked using a discovery board so that your team can see which items are coming up next for delivery.
Once items are brought into a sprint, the progress of delivery may be tracked on a delivery board. Both discovery and delivery boards are examples of visualization boards (or information radiators). The delivery board in particular is used to track each item’s progress from definition of ready to definition of done and eventual deployment to stakeholders. A definition of done may include updating system documentation intended to support the next effort on the asset by providing an updated reference of the current state of the asset.
Evaluation done at this point includes “Is this user story ready?”, “Is this user story done?”, “Should we deploy?”, and other questions of that nature.
If You Remember Nothing Else
Analysis with an agile mindset allows your team to gradually dive into detail about your solution, taking advantage of the learning you received from delivering earlier output. This iterative approach to analysis also provides your team with regular opportunities to decide whether to commit to, transform, or kill your initiative.