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:
- Exist to help people have conversations about a small set of requirements
- Have an associated cost (an estimate)
- Offer some business value to people such as stakeholders or end users
- Help stakeholders prioritise requirements
- At some point may be implemented
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.
Recent Comments