When I first started learning about user stories as requirements in a product backlog, the concept was a bit tough to get my head around.   Coming from more a traditional waterfall background and being baptized into Scrum by fire, there were key components missing from the folks I was learning from.

After my training, it became clear pretty quick that we weren’t using some of the core foundations of Scrum which attributed to a lot of problems.  More on that in a future post.

The clearest message was that a user story is a vehicle to a discussion.   The text in the story isn’t the be-all-end-all of what is to be done for that particular requirement.  Discussion with the customer, product owner and team is necessary to get a sense of the business value behind the story.   There are a lot of great books, particularly AppliedUser Stories by Mike Cohn.  I just finished the first 3 chapters tonight and it’s helped me plan out a workshop for the team to help out with the problem we had today.

What went right:

• we time-boxed the first 3 stories
• each team member read one story (to keep everyone interested)

Many things went wrong:

• business value wasn’t clear for one story:  the product owner was clearly frustrated near the end, the team kept hounding him with useless implementation and use case scenarios.
• the whole team got sucked into talking about implementation details:  This is a case that happens a lot – “If we build it this way, it’s X points.  If we build it that way, it’s Y points.”   The Team should decide on the implementation that best serves the business need.
• the Scrum Master (hmmm, who could that be?) stopped time-boxing after the 4th story and let the meeting fall off the rails:  This is odd, I’m usually really good at this but I should have stopped the meeting when the time expired.  30 minutes turned into 1.5 hours.
• no one on the team wrote any notes or scribbled on the story card

What we’re going to try next time

• role reversal:  I’m going to have a workshop with the team, product owner and a stakeholder.  The product owner (very technical) and stakeholder (technical enough for this exercise) will play the developer.  The team members will play the product owner role.  We’ll go through a story writing exercise.   We’re small enough to try this out.
• REAL story writing sessions:  this is a great idea to try if you haven’t quite got the hang of user stories.  The team, customer and product owner will meet, talk about the requirements and write the stories together instead of having the product owner write them himself.

The techniques I’m going to try next time are directly lifted from Applied User Stories but mixed in with what I know seems to work well for our Team.  I’ll post an update after the session.