- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
Knowledge Artifacts
The following has been adapted from a project that your authors are involved in called Nucleus—The Minimum Viable Knowledge. As its name suggests, the intention is to specify the absolute minimal amount of documentation that enables the project to succeed. We are equating documentation with knowledge on the basis that as you learn things during business analysis, you record them. This is the knowledge that must be gained and recorded for the duration of the project and longer.
What follows is the bare-bones minimum. We are certain that you will want to add to this. We doubt you want to subtract.
Project Goals
Start at the top where you find the organization’s goal. In most cases, the goal of the organization is to make a profit. That much is obvious, but the interesting thing is what it does to make a profit. Even if yours is a not-for-profit organization, it does the same as a profit organization, it performs business activities. These can be supplying services, producing products, or almost anything else. These services are supplied to the organization’s customers. For the purposes of business analysis, it is expedient to divide these into customer segments depending on what they need.
The customers keep buying from the organization only if it provides some value to them. This means that we can derive a value proposition for each customer segment.
These three artifacts—the organization’s goals, the customer segments, and their value propositions—can be bundled together and called the project goals. In short, the goal of the project is to deliver the value proposition to each of the customer segments and thereby deliver value to the sponsor. You can see these artifacts in Figure 7.8.
)
Figure 7.8 The minimal, viable set of knowledge artifacts.
You must ensure that everybody on the team is well and truly aware of the project goals. Sometimes in the heat of battle they are forgotten, corrupted, or ignored. The project wanders off course, rudderless, and the final result is of little use to the customer segment. It fails to solve the right problem and does not deliver value.
Certainly, you will probably discover along the way that your goals are changing as the organization’s ecosystem changes, or that a new and better goal/segment/value emerges. It happens all the time. Reconvene with your sponsor and your team, discuss, argue, and re-establish the project goals collection. It is, after all, the supreme navigational artifact for your project.
To provide the value to the customers, the sponsoring organization usually requires some solutions—automated systems, machines, services, and so on. And that brings us to our next bundle of artifacts.
Solution Scope
The solution scope is a collective that links the information you gather about the business processes that makes up your chosen solution.
You might have discarded the notes, models, and sketches used in your safe-to-fail probes, or you might have kept them. They are probably interesting, but not all of them are necessary keepsakes. However, because you are making your decisions based on your safe-to-fail probes, we urge you to transfer the rationale for any decisions to the documentation arising from your probes.
For example, you should annotate your context model with the reasons that you chose that particular scope over another. That alone will save you hours of rediscovery and debate down the road. This applies to other models and sketches. Leaving behind your reasons for something is just as important as the something you’re leaving.
The solution scope collective should show the reason that scope was chosen.
There are business rules associated with any business scope. These are the rules that you would have discovered earlier in your investigation. These rules should be recorded so that anybody attached to the project has access to them. Your organization might have a central repository of business rules, so there is no need to repeat them. In the central repository, you might find it convenient to tag any rules that are applicable to your project to save the time of people who need to refer to them.
The solution scope collective also contains a list of business events. Business events are a natural way to partition the solution space and lead to natural solutions. We urge you to use them. The reason business events work so well is that they originate from the outside. In this way, they partition your solution in the same way that your customers see your solution. They are not arbitrary internal choices dictated by your politics or your internal management structures.
Story Maps
The story map shown earlier in Figure 7.5 is derived from the business events. We described in the previous chapter how the top row of the map is a set of cards—one for each business event. The cards shown in the columns below each of the business events illustrate the way you have chosen to implement them.
){kind=link}
The advantage of a story map is that it gives you an overview of the solution and how you intend to develop it. The story map as we described it in the previous chapter is primarily a breakdown of the functionality; it shows the tasks needed for each of the business events. Along with the tasks, the story map should show the quality needs or nonfunctional requirements. These indicate how well the product carries out its functionality. You might also attach any wireframes or sketches that you have developed. Finally, make sure that, where necessary, you attach the rationale to your story map artifacts.
Leaving behind your reasons for doing something is as important as what you did.
One reason for using a story map, or any other form of backlog, is that stories are an outstanding way of tracking the progress of the project. A simple count of the number of stories is far better than guesswork. This count can be augmented by adding story points to the cards.
So if stories are useful, why don’t we start with stories and forget this other documentation stuff? The reason is that stories are almost always about a solution. If you start the project writing about the product you intend to build, you are thinking about a solution, not the problem. This means you have assumed the solution. Without correctly understanding the problem, any solution is possibly the wrong one. Stories are often spoken of as an invitation to a conversation about the problem, but they are still stories about an assumed solution. That is far too narrow a view to help you discover the real problem.
That brings us to the end of documentation, or to use more acceptable words, the artifacts from your analysis that the developers use to deliver, and what you are leaving behind for future generations of maintainers. Do this carefully; it is probably the most significant determinant of the future cost of maintaining the product that you are so lovingly building today.