User stories: Does the format matter

We are all familiar with the suggested format of a user story

"As a <role> I want <something> so that <some benefit>"

What's great about this format is that you capture a great deal of context for the developer with very little information presented. And while I believe this context is important, I don't believe the specific format is the most important thing to worry about.

First off, when you take a look at many backlogs the repetition of "As a blah ..." can drive you nuts. Second, most backlogs you see, stories are written - "As a user blah ..." and that's no value to anyone anyways.

So where am I going with this ??

What's most important about the user story is really the conversation that it generates and the acceptance tests discovered during the Sprint planning sessions where the Stories are explained. I was present in a Sprint planning meeting the other day, and although the Story was not all that well written, the understanding gained during the Sprint planning discussions was unbelievable. In fact it was such an eye opener for me. At that point, once the understanding is reached, the Story is just a label.

Now don't get me wrong, knowing the user and the benefit is great to know however in order of priority, I'd say Conversation is #1, Conditions of Satisfaction or Acceptance Tests are #2 followed by the Story format in a distant #3 spot.

Not sure what you folks think.

My 2 cents, don't get hungup on the format, get hungup on the conversation!!!

Happy planning!

Jack

 

 

Whose doing your Sprint demos

Ok, this has to be the shortest blog post ever. But just maybe it's something useful you can try. So this is more of a tip than a blog post.

Typically during the Sprint demos the devlopers do the dog and pony shows. They coded it and so they generally like to do the demos.

What we tried out at my last gig, was for the QA folks to do the demos. What's good about this is that it really shows the chickens and pigs that the loop has been closed.

As we all know, it's acceptance tested stories that really count. Code complete is meaningless. When QA is put on the spot to do the demo's they really ensure that the feature is understood and is working well. It also makes them feel important and part of the process.

Try it, even rotate the responsibility after each Sprint.

It worked in our context and may well work for you.

Let me know

Jack