A previous entry described how to plan using cost and business value estimates. It’s really very simple:
- The customer chooses stories and the order in which to implement them, the most valuable first, the stories with the best value/cost ratio first, the stories with the most demo potential first…
- We implement the stories one by one, in the order specified by the customer
- If we don’t have enough time at the end of the release, some low-value story might not get implemented
- If we have some time left, the customer chooses another story, from the list of “if we have time” stories.
Is the real world that simple? Of course not. You have to take into account risk.
Some of the stories are riskier than others. What could the risk be ?
- The story implementation requires some new tools, a new package, a new algorithm. Anything new is always risky (or as Jerry Weinberg says “Nothing new ever works“).
- Implementation requires coordination and cooperation with another team, another division, another company. The further away, the riskier.
- The functionality affects many parts of the application.
- Your risk here
For example, in the current release there are two risky stories: one is the redefinition of an existing product, the second one is the definition of a new product. Why are these two stories risky?
- The redefinition of the first product will allow us to simplify product handling. This refactoring will touch most of the modules in the application. We will have to migrate existing data. The result has to be completely transparent and compatible with the previous release.
- The definition of the new product is a trial for a new way of structuring products. If it works out, we will (re)structure all of our products this way. If it doesn’t work…
- These products have to be defined by another team. We specify the changes, they implement them and (after a while) we get back a file containing updated product definitions.
How do we deal with this?
- Risky stories get a higher priority. We schedule these stories early in the release. The product re-definition was the first story of the release. Coordination with the product defining team started before this release, so that the new definition would be ready at the start of the release. And lucky we did it this way: due to a misunderstanding, the product re-definition was only half complete. And the person responsible for these product definitions went away on holiday. Because this risk materialized early in the release we didn’t panic, we have some time left to correct the situation.
- We have a fallback plan. Plan B.. What do we do if the worst comes to the worst and the story fails completely? In both cases, the fallback is to continue to use the current products. These products are not as effective to work with, both for IT and users, but we can get the job done.
So, the normal case is very simple: implement stories in business value order. But for some risky stories you also:
- Identify the risks, their severity and their likelyhood. Focus on those that are severe and likely
- Find ways to avoid the risk or to deal with the materialization of the risk
- Schedule the risky stories earlier in the release, so that you have the time to deal with the risk.
