Consider that your specifications (called User Stories in Agile) are the foundation that your system will be built on. If the User story is incomplete, your foundation will be incomplete.
KRS employs 3 techniques: the User Story detail, the 3C’s of User Stories, and the high level Story Map. See how these simple, practical techniques can help you.
The User Story Detail
We use a simple framework of structuring the story as follows: “As a ……., I want ……, so that …….”.
This clarifies the starting point of view, by explicitly stating the role upfront. If the role is a client perspective, that can be very different from a management perspective. If all your “As a ….” introductions are management roles, perhaps you should reconsider if you are taking your clients into account. The stories tend to come out quite differently once you work from a customer-centric position. Just a thought…
Then you have an opportunity to describe the meat of the requirement in what you want. KRS believe that the requirement must always be a business requirement, not a technical story.
Finally you specify why you want this feature, by completing the “so that ….” piece of the story. This is the hardest part – we often want something but battle to define why. Spend some time on this, as some stories may drop away or change significantly once you truly engage with “why”. This will also help you to prioritize development for stories based on business value.
The 3C’s of User Stories
The 3C’s were first coined by Ron Jeffries: Card, Conversation and Confirmation.
User Stories are usually drawn up on big index cards, so we have handled the first C above – the Card.
The next C is for Conversation. Most project failure centres on poor communication. So the Card cannot be the only means of communicating; it is a foundation on which understanding must be built through much dialogue. Think of the Conversation as an open dialogue between everyone involved in the project, continuing through the life of the Story.
The 3rd C is for Confirmation. Each aspect of the Story must be confirmed through Test Cases. Draw up test data that covers all the scenarios possible, and confirm that your Story works! These Test Cases are a truly valuable resource throughout the project, so again spend quality time to design the Test Cases before development starts.
Ensuring that the Story is testable also helps to define the Story at the right level of granularity. Broad sweeping statements like “As a manager, I want a warehouse system, so that I can control my stock” is clearly not a testable story!
The Story Map
This is easy – arrange all your Story Cards into logical groupings and stick them up on a wall. The groupings can be business departments, or sub-systems, or whatever makes sense to you.
What’s really cool about a Story Map is that it’s a physical object that everyone can see.
It reminds us continually of our business goals and the people who use our software. You can mark the Cards as the Stories are delivered, so you can see at a glance what’s done, what we still want to do, and, if you’re the type to read between the lines, what we haven’t thought about. Story Maps bring the high-level view back into Agile, sometimes missed at the small iteration level.
Conclusion
It’s only with practice that you’ll get really good at these techniques. And a word of warning – when you see how valuable this approach is, you might even become an Agile evangelist like KRS!
About the Author
Lorraine Steyn is a founding Director of Khanyisa Real Systems, and a self-confessed nerd. KRS are Microsoft Gold Partners, who specialise in large database projects with high availability requirements. Khanyisa Real Systems are leading proponents of Agile project management principles.