From my Scrum Master experience, I find that everything starts with user
stories. If your user stories are bad, everything can go downhill, no matter
how good your process or team is.
I wanted to write about characteristics of
user stories, but I thought it would make more sense to take some examples
and discuss them. Here are a few example user stories
1. As a user, I want to create a new account, so I access the system for my day job
- This story adheres to a commonly used template - defining who is the actor, what is needed from the story and some business justification.
- I like the 3Cs defined in XP - Card, Conversation, Confirmation.
- Card - The story is short and can be written on a card. It is not a legal document covering all the possible edge cases in the world.
- Conversation - The story does allow for some conversation - the team can ask questions or express their opinions. For example - the team can have questions about what is all data that is needed from the user in order to create a new account, or what is the expected UX etc. The conversation about the story becomes part of the story even if all of it isn't explicitly documented.
- Confirmation - The story is defined well enough that we can write an acceptance test for it. However, no team I know of does perfect Agile / Scrum, and almost all teams I have worked with have lacked in the area of TDD and ATDD. In absence of acceptance tests, I like to redefine the third C as confirmation received from the Product Owner in a demo.
- The story adheres to INVEST -
- Independent - The story can be made to stand on its own 2 feet.
- Negotiable - Since the UX or parameters to be accepted from the user aren't expressly defined, the story can be thought of as negotiable
- Valuable - The story adds value by allowing a user to register a new account.
- Estimate(-able) - Teams should be able to put a time / story point estimate on this story - possibly after some discussion.
- Small - The story doesn't seem overly big. It looks like something the team can accomplish in a reasonably small sprint.
- Testable - The story is testable as someone can query the server or database to see if the account was successfully registered.
- Overall, I like this user story. This is a decent candidate for a 'ready' backlog.
2. As a user, I want my app to be fast and responsive, so I
don’t get irritated while using it
- Although this story adheres to the format, the 'fast' and 'responsive' words in the story make it non-testable. The parameters need to be defined in ordered for a tester to objectively pass or fail any implementation.
- Although the sentiment behind the story is good, I wouldn't call this story as 'ready' for a prioritized backlog. Some more work needs to go into the story to define it better.
3. As a maker of smartphones, my company wants all apps in
all app stores to be supported on all of my devices across formats and variants, so my company gains 100% market share
- Just by reading the story you can tell that is (a pipe dream) and HUGE! It also looks completely non-negotiable.
- I'd call this a terrible candidate for any backlog. A lot of work needs to be done on this story before it can be worked on by any Scrum team.
4. As a developer, I want to connect to the database so
that I can query for various pieces of information
- Unless your product is the database itself, I don't like this user story too much.
- Connecting to the database, getting the development environment setup and compiling etc. should be done as a part of Sprint 0 - the development and test set-up sprint. This should not be something that is needed in a product backlog when you start adding business value to the product.
5. As a tester, I want to have a separate test environment
built for me, so that I don't have to test in production environment.
- I like to think that if your organization doesn't have a separate production and sandbox / test environments you may not be ready for your sprint cycles yet.
- Having said that, I want to confess that this is a real candidate story from a project I have worked on. The problem we were facing was that our regular sandbox / development environment was going through maintenance causing our servers to go down randomly. This caused a lot of pain points for everyone on the team. It was impossible for us to build an entirely separate test environment. The story was too big, and there was no real value-add to the business, as the system maintenance was scheduled to be complete in about 2 weeks time.
- We just had to deal with the sandbox system maintenance nightmare by improving communication between the teams involved.
6. As a user, I want to be able to connect to database
- This story has a lot of problems. You can tell by reading it that it does not spell out the business value.
- Users usually don't connect to database, they use the UI to do various actions - which may entail connecting to the database.
- We need to carefully think about - the actor, the functionality and the business value when we write user stories.
In conclusion, I believe that writing good user stories is really important. Almost all the teams I have worked with find writing good user stories to be really hard work. I like to consider writing user stories as a matter of continuous improvement. You can possibly start off with some bad ones, but it really helps if you devote time and think carefully about the stories.
No matter how good or bad your user stories are, I recommend having a meeting where your team discusses the user stories. This allows for conversations about the user stories between the team and with the product owner. This lead to better shared understanding of the problem the team is going to solve.
Another quick point - Most Scrum Masters I know have talked about a definition of done at some point, but I think it is also important to talk about a 'definition of ready'. This definition can give the Product Owner some guidelines about what your team expects from the user stories in a 'ready' backlog / queue.
| Rate this post! |
☆
|
☆
|
☆
|
☆
|
☆
|
