For many Agile teams the vague user stories are serious impediments to team performance. Imagine the amount of time that is wasted in trying to make sense the ambiguous customer requirement, not to mention the accrual of technical debt when our requirements assumptions are way off. User stories that don’t express business value should not be on the product backlog.
It is the Product Owner’s responsibility to ensure that the features being worked on will yield the expected return on investment. In many Agile teams the design of the implementation, or the how thinking is crunched into a time boxed Sprint Planning ceremony even when backlog grooming was performed. The backlog grooming sessions we know, is a ceremony not covered by the Scrum framework.
Agile principles and values advocates a Just-In-Time (JIT) way of working, delivering barely sufficient artefacts in a JIT manner. Many teams, unfortunately, go into analysis paralysis panics, with no real output at the end, which is really concerning.
The Product Owner has a huge job in managing the backlog and if this role is not supported in any way or form, then the outputs will create non-value adding waiting time (waste) for the teams and frustrate the customer that is paying for value to be delivered every two weeks. When you have nothing or very little to demo to your customer, there will be harsh words.
My 10 Tips for Creating User Stories that Create Value are:
- Meet regularly around the backlog with your team to discuss requirements, raise questions and allow time for the solution to be absorbed into people’s consciousness. The effect of this exposure will pay off in the Sprint Planning meeting.
- Form close relationships with the stakeholders that are key inputs to the project’s success. E.g. Product Owners and UX designers, potential consumers, developers, stakeholders etc.
- Product Owner must validate the viability of the user story and have supporting use cases, success criteria, revenue projections etc.
- User stories must meet the INVEST criteria of user story writing.
- All stories must have complete acceptance criteria for happy and unhappy lines.
- Product Owners and teams should understand the big picture, but focus on the now picture.
- Get User Experience designers in as early as possible.
- Avoid dependencies like the plague.
- Have a reference user story, one that can be used to compare any new user story to, in order to validate size and complexity reference.
- Ensure that a definition of ready exists that the delivery team create, detailing what is required on the story before it will be committed to. The team also needs to agree on the definition of done for user stories to ensure consistent quality and common understanding.
The list is by no means exhaustive, and I encourage you to tweet your thoughts to us @Agilocity_ZA or comment below.