The best user story!

For the last how many of years I have worked in agile practicing teams, I have seen many different styles of acceptance criteria on user stories and was part of the discussions over what the best approach is.

I have worked with many wonderful BAs who genuinely want to make the user stories spot on for the team. But in the same time I have seen the team is making the user story complicated and the BAs just go with that flow as well making their job far more difficult.

This is a list of different patterns I have seen and my thoughts. Again, these are my own views.

Pattern 1 : High level requirements in bullet points

The team doesn’t have a clear idea of the scope, the design, complexity of the story. The estimations to reality of effort will be far off.

I have seen at refinement, people ask, oh [name] you know what needs to be done yes? So we will go with that. It doesn’t matter that one person in the team understands what needs to do. The whole team needs to understand what happen in the story. When I say, the whole team, it includes the whole team. Product owner to Business analyst to Architect to Developer to Tester to support teams and any other parties involved. I am not talking about detailed technical information. But what this story is about, its impact from each job function point of view.

Patter 2 : Acceptance criteria looks like a test plan with every possible scenario

No one can think “All” possible scenarios. I have seen some team asking the BA to write detailed acceptance criteria and in the refinement meeting going through each scenario one by one. Less discussion time and high possibility of team getting distracted and disengaged specially when team is working remotely. I know I have.

I am happy to encourage healthy discussions to understand the story, discuss the scope of testing. But I do not think we need every scenario that we need to think of in the story. This can block the analytical thinking of the team. They expect the scenarios to be in the story prior. And my biggest worry is that the Test team becomes check box tickers than using their analytical mindset to think differently scenarios.

Its all about the quality of the story but not about the quantity of the scenarios in the acceptance criteria.

Pattern 3 : Not defining the business value

Without knowing what the business value of the story, there is a risk of team not engaging with their work. I have seen that when team know what the business value of the story is, they engage more. Come up with good questions and discussions. They started to think out of the box.

The team also will start to understand their part in the value adding process. I have seen that the product team come up with new requirements but once that feature goes live, there is no feedback of its performance. Also I have seen when product team come back with feedback and shows the effect of new feature implemented results engaging teams. They start to care about the product than doing what they were told.

Pattern 4 : Story is written in a way to please the person who ask the most questions

Yes, this is something I have seen more times than I should. The story is written in a way according to the most vocal team member. If they are happy then thats it. If someone asks a question, oh [name] knows it. Or [name] tells no need to worry about it without explanation.

This is not a good pattern as we need to write stories that the whole scrum team understands. We need to understand the story as it will come to each individual to develop/ test or support. If we don’t then the [name] becomes a bottle neck and everyone is blocked.

Pattern 5: One liner description of what the story to be implemented

I have seen many technical stories comes with a one line or two. In the refinement session there is a long discussion but the story is not updated as developers know what they need to do. Sometimes we hear this doesn’t need testing or I will add a comment on how to test.

Also, the product owner / BA doesn’t understand why this story is needed and heavily depends on the tech lead for leading it. I am not saying this is bad. But it have a high risk. Everyone needs to understand why we play the story, how we are going to implement , what’s the business value (short term or long term) and how do we test it.

Pattern 6 : Product owner dictate the story

I have seen sometimes that PO tells what the story is an the BA writes it. When the team have questions, the BA is bypassed because their lack of understanding of the requirement.

Business analyst is there to analyse the issue/ requirement and gather the people who can build the solution, facilitate and write the stories to replicate the need and the what. If they are depending on others to tell what to do, then I do not think they are being true to their job description and also team may feel the role is not needed.

What is the right balance?

A user story is a representation of the work that needs to be done. Expectation is that everyone in the team understands what needs to be done from their respective function. Refinement and 3 amigo ceremonies are a great opportunities.

Scrum teams can do more to make sure everyone understands the work. The culture should be encouraging for everyone to speak and share their ideas and if some team members need time to think, then provide that too.

Most importantly, The responsibility come to individuals . If I am assigned to this work, do I know what to do? Not another member of the team but do I know what to do. If not, ask questions, do your own analysis and come with questions before the work hits you. You cannot expect the person who write the story will answer your questions without you asking them.

Every team is different. Rather than go with the flow, everyone should contribute to make sure the sprints go smoothly. There is no right answer to how user stories should be. You may have a personal view but its better to work with the team to find what is the best way.

So rather than prescribing how a user story is, best to be open minded and change it with the team. Add/Remove sections according to the common areas team ask questions. Build the user story and its format with the team.

Why? The more we understand the work, we are likely to find issues early and deliver a high quality outcomes.