Defining Story Requirements with Templates

[Daniel Pettet]

When I think of technical health for the platform, 2 things come to mind:

1. Story Definition

2. Peer Reviews

There is nothing more important than these 2 aspects to ensure high quality. If there's only 2 things to focus on for improving quality and technical health then make it these 2. 

Stories play a critical role and impact:

1. Time to implement
2. Implementation quality
3. Time to understand + review
4. Test quality
5. Ability to define tests (automated or manual)
6. (to some extent) Ease of Upgrade

So what if my story is a jumbled mess of thoughts?

Think about the number of people that might read or review a story. There's the person who defined it and may need to understand it later, the product owner and other stakeholders, developers and testers. If a story is confusing or hard to comprehend then you've just burnt time and energy for 4 plus people. In the best case, they'll take the time to read, consult on, understand and improve the story. In the worst case, they'll simply skim over it and to some degree ignore it. Multiply that by the number of stories defined and you've got a heavy burden to bear. In larger and more complex setups, the number of people reviewing is also higher.

For this reason, I strongly recommend the following: 

1. Clearly define a list of personas for use in stories (helps clarify context and need).
2. Always ensure the business value is included in the story and bullet proof. It should always be challenged/challenge-able.
3. Use a consistent format for acceptance criteria. Avoid any stories like "see attached document for details".
4. Track technical approach, open questions and knowledge transfer separately (ie, own fields or scrum tasks) to ensure speed to read and comprehend is prioritised over technical details
5. Use scrum tasks to ensure critical steps are being executed (eg, peer reviews)
6. Have a clear definition of done (dev complete, ready for testing) 

Below you'll find a template with examples that can be used as a guide to improving story definition.

 

I see the light!

If this is making sense then the next steps to consider are:

1. Setting up a default platform template for story records
2. Providing a guide and documenting with other Agile/Dev/Product owner documentation (include as part of on-boarding material)
3. A quick how + why session for the team to help with adoption
4. Consider documenting sample stories as the "best practice" that cover topics from integrations, documentation, bug fixes through to performance and monitoring type stories. This will help others understand how to use the template in various contexts.

Once this level of maturity has been reached, it opens up the door to improving test management. Clearly documented stories enable rapid and high quality test definition.

[Cire]

Very interesting !!