- Jack Be Nimble
- Wicked Problems and Gordian Knots
- Jack Be Quick
- Jack and Jacqueline Jump over the Candlestick
- Agile Business Analysis and Iterative Development Cycles
- And Jill Came Tumbling After
- Knowledge Artifacts
- Jack Sprat Could Eat No Fat
- Traditional Business Analysis
- The Requirements Document
- They Have Licked the Platter Clean
Agile Business Analysis and Iterative Development Cycles
In the previous chapter, we spoke about the story map. You might prefer to use a flat backlog, or a Kanban board, or something else—but for the sake of simplicity, we shall assume you and your team use a story map.
The story map is a significant artifact, as it acts as the central repository for project knowledge. The map is loaded by the discovery activity, refined by the product people, and unloaded by the delivery activity. This is summarized in Figure 7.5.
Figure 7.5 The story map is the hub of the project. Each activity is contributing to, and feeding from, the map.
The Product Owner Coordinates
In the diagram, we referred to “product people.” For many of you using Scrum, this would be a product owner and/or a product manager. For some, it might be a project leader. Whatever you call it (we shall talk about the product owner), this role is responsible for the refinement of the story map/backlog and its prioritization.
By setting the priority of the stories, the product owner is directing both the discovery and the delivery. Let us say that the discoverers—probably business analysts—have discovered all or most of the business events. The business events would be revealed fairly early in the discovery activity. Once they are known, a rudimentary story is written for each business event, and these are added to, and form the top row of the map.
Once there, the product owner, in conjunction with the stakeholders and the rest of the team, prioritizes the event stories. This prioritization establishes the work sequence for the discoverers and deliverers.
The Discovery Activity Responds to Priorities
Discovery in the beginning can be rudimentary and would not delve too deeply until the need for detail has been established. However, once the priority for each business event has been established, the discoverers—presumably Jack and Jacqueline acting as business analysts—can focus their attention where it is needed.
Figure 7.6 shows the discovery process adding detail to the story map.
Figure 7.6 The discovery activity remains much as we have described it so far, but now it is focused on the business events—and the parts of those events—that nave been allocated the highest priority.
Once most of the business events have been discovered, it is possible to conduct the discovery activity in such a way as to concentrate on what is considered to be important by the product owner, and to ignore the low-priority events.
The story map enables the business analysts to see the gaps in the high-priority events, and to focus their discovery such that they are constantly feeding the delivery activity. Naturally enough, the discovery has to be quick enough to feed the map so as not to delay the delivery. However, we stress that the stories the discoverers add to the map must be the right stories (that’s what this book is about); otherwise, delays occur when the wrong product is delivered (and rejected) or the deliverers have to spend time figuring out what the story should be.
Now let’s look at the delivery side of the process, shown in Figure 7.7.
Figure 7.7 The delivery activity is also responding to the priorities assigned to the business events. Stories are developed iteratively resulting in partial releases to the customers. Note the feedback from the development process—this helps the product owner to fine tune the map.
The stories are delivered to the map just in time for the developers to select the functionality they and the product owner decide is suitable for their next iteration, or sprint. This will of course require a close collaboration with the discoverers and the product owner if the right stories are to be available at the right time.
The developers provide constant feedback to the story map and the product owner. Sometimes the developers discover things that cause changes to the story map, or result in changes to the refinement of the map.
This is all iterative, with the discovery and delivery activities iterating to the same rhythm.