I’ve been using the Design Comics site recently for putting together some better presentations. Here’s a system that worked well for me:
One of the most interesting observations Ajit and I made when we finished our inception a while back was that defining a system too early puts constraints around the way you work and potentially hinders learning.
We set out putting together a mental model of what we thought the system should be and what the scope of the project entailed. We did lots of brainstorming, gathered tons of input, asked lots of questions and inevitably, had fair amounts of discussion as we tried to understand it from different points of view. We tried using some software based systems like a spreadsheet, or some modelling software to capture the information we had, and eventually got too frustrated as we struggled to deal with both what we needed to model and how we were going to model it.
We found it’s much easier to work out how to model things once we understood what sort of things we needed to model. It didn’t mean we didn’t try modelling it at all. Rather, we used cheap techniques to quickly change the way we wanted to represent them. In the end, we used colour coded papers, index cards and broad categories on flip charts to represent different types of information, allowing us to group, category and reclassify bits of information quickly and easily.
Our system let us deal with larger concepts when we needed to, with the ability to drill down into enough detail to have better conversations with people closer to the project. We ended up distributing the information we modelling into more common formats - a simple spreadsheet for stories, and another for a risk log as well as some high level diagrams representing the system.
It felt much more satisfying to uncover the natural groupings of information instead of trying to cram information into the system we happened to pick.
I’ve worked with some analysts who think their job is to scribe, writing down what users say into documentation. Sure, some skills of an analyst might require some scribing though rarely is it the entire job. Here’s a list of things I’ve observed excellent analysts focus on.
Most of the teams I work with prefer using story cards to capture and manage requirements. For analysts who write story cards, it’s important to remember that they are that “placeholder for a conversation” and it’s useful to know about the three C’s, and understand the INVEST principles that make more ideal story cards. In this post I’m going to answer the frequently asked question: “How much detail should go into a story card?” Of course, please remember that this is just my answer to the question and unlikely a definitive one.
Before I begin to answer, I guess it’s important to understand why we even bother with story cards, something definitely worth a whole other post (and I’m sure there’s plenty of great ones out there). I’m going to distil this to just the essentials and skip the why (you can read it in other people’s posts). For the purpose of this post, I’m going to assume that story cards:
The Short Answer
You want to have enough detail to meet the objectives above balanced against the cost of capturing and maintaining that detail in order to support as much change as possible.
The Long Answer
I like to draw the diagram below to visualise how much effort I’d put into collecting detail.
For stories that need to be implemented now, you want to have enough precision that allows developers and testers to be clear about what needs to be achieved. The waste of not having enough detail here is essentially rework in many of the downstream activities. If critical detail in a story is missing, it will lead to misunderstandings that, in turn, leads to bugs that, then, leads to additional coding time and additional testing time, delaying delivery of the business value. What is important at this stage is that everyone involved (the business, analysts, developers, testers, etc) share the same detailed understanding of exactly what is being delivered and what is exactly not being delivered.
For stories that need to be implemented in the distant future, you don’t need the same level of detail. The waste of capturing too much detail too early is essentially rework at the analysis level. Depending on how requirements are managed, this can be costly. Conditions change that may change requirements not yet in production, and I’ve seen many analysts who’ve written down so much detail and invested so much of their own time that they refuse to deal with the change. The want to avoid the change because they now have to rewrite reams and reams of documentation, or drop the last month or two of work to develop a different and better solution. What you need for stories in the distant future is enough detail to allow people to have that conversation over the same thing without confusion, whilst minimising the cost of capturing detail unless it impacts things like estimates, priorities or business value.
The Summary
Although it sounds like I’m saying don’t worry about future requirements, my emphasis is all about balance. You want to balance the costs associated with collecting and maintaining details for requirements that may or may not end up being implemented. Precision has a cost associated with it, and this cost always needs to be weighed up against its value. Excessive precision too early may increase cost via additional rework at the analysis level. Lack of precision too late may increase cost via additional rework in downstream activities such as development and testing.
Further References
James Shore writes more about the life cycle of a story and when you might want to start creating them. Read about it here.