I’ve already said that my job is to feed the programmers with work in the form of stories. The stories are designed to fit into a one week unit of work. This is useful because it shows that progress is being made. But it’s hard to tailor iteration stories to a week, and it’s even harder when the iteration story is tricky to understand in the broader context of the code to support the full user requirement. I have to understand how the small story fits into the big story – otherwise I can’t be sure the team is building something of business value – I can’t map it back. So, that’s a priority and that’s now done. I have only been able to get it verified lightly by the solution designer, architects and a couple of BA friends. But, no mattter, it’s still helpful and provides a kind of ‘table of contents’ into the wider system. I also did a surreptious end-to-end activity model. I broke it up into sub-activities based on the kind of jobs people actually do now. Activity modelling really works to show how user stories are called sequential to satisfy a particular workflow. And it’s fast. It’s pretty obvious on a high level and the high level is sufficient for this exercise.
If you enjoyed this post, make sure you subscribe to my RSS feed!