Recently we worked with a client that was looking to improve their agile requirements. Although they were creating user stories, they didn’t feel like they captured enough details in the user stories, and as a result they encountered many issues in User Acceptance Testing (UAT) where the requirements had been misunderstood.
They summarised the problem as:
For me the biggest challenge is getting people to think in advance, write up the user stories in advance, choose the relevant stories and populate information for stories so a developer has a full brief of what is needed. Things tend to get added or information shared on the fly.
When we arrived at their offices we quickly understood the problem. It’s something we commonly see in agile teams.
They had a large wall space dedicated to their Product Backlog and Sprint board. Nice!
Taking a look at the boards we noticed a couple of things:
- The user stories were pretty small and each developer was assigned a couple of stories.
- The backlog had a lot of stories and all seemed to be at a fairly detailed level.
- Every story was in the Connextra format: “As a …, I want …, so that …”
From a further discussion we realised that there were a couple of issues to address:
- They were treating the user stories as requirement documents.
- They thought they HAD to use the Connextra format for user stories
- The developers were working as a group of individuals rather than a team
We like to talk about the 3 C’s of user stories:
- Card
- Conversation
- Confirmation
Card, is an index card the story is written on. It is intentionally small, so that you can’t include alot of details. The Card is just a reminder to have a conversation about the requirements.
Conversation, is one of the most important parts of agile requirements. This client and many others replaced the conversation with documents in a tool attached to the user story. Their frustration was that no one enjoyed writing the documents, and they tended to not give the right level of detail either. It also led to ambiguity and rework.
We taught them how to rather have a discussion about the requirement with the customer, Product Owner and team members. We used mindmaps as a technique to document this discussion, and help them uncover unknowns and assumptions. Everyone agreed it was a quick easy way to ensure everyone was on the same page regarding requirements, and that it would be much easier to get people to participate than getting them to write a document.
Confirmation, is the acceptance test. Knowing what the customer expects it to do for them to say the requirement has been delivered. Talking about this before any work is done, can help prevent many issues and rework. It is a natural question to explore when creating a mind map of a story.
Let’s also take a look at the format of User Stories.
Here is an example story from this client:
As an admin who has to fix campaign errors I want one report that lists all campaigns with errors so that I don’t have to manually select each campaign individually to find out which campaigns have errors.
The Connextra format was created as a thinking tool to ensure that instead of focusing on the solution description, agile teams think instead about who needs a particular feature, what they are trying to achieve, and why this is important. However, many teams mistakenly believe that every users story needs to be phrased in this way. It often results in a lot of time hammering requirements into the format, and making really simple concepts seem complicated.
Consider instead:
Admins want to be able to quickly fix campaign errors
We taught them to focus on discussing who, what and why with the mind map and then writing a a short sentence that is meaningful to the team and customer. Maybe just “campaign errors report”. The developer seemed quite relieved to find out that he never had to hammer a requirement into the As a … format again 🙂
Try it for yourself
We now have a Ready-to-Use Workshop to teach your teams this method.