Blog Posts

How Perfect User Stories Kill Your Team's Engagement

by ,
08.07.2012 10:34 CEST - Comments [6]

Many ScrumMasters and Product Owners are constantly searching for the perfect User Story format. The “As a <Role> I want <Functionality> so that <Motivation>” schema is widely used, but in many organisations it has become a standard to put way more preparation than that into the definition of the User Story's details in preparation of the Planning meeting.

In the teams I've worked with recently stories usually contain the “As a …” phrase, a number of explanations, a number of acceptance criteria, and some attachments as needed. I think it's fair to argue that this preparation, that sprung from the imagination of one or two people, constitutes some serious up-front design that has several severe consequences.

The obvious thing is that such stories are not based on the latest state of the project, because they have created, in all detail, before their previous sprint was finished and reviewed. This alone makes it just so much less likely that teams will find the best, most effective solution to a problem.

Perhaps a bit less obviously, such complete user stories will also put the developers (and everyone else not involved in writing them) at an unfair disadvantage for the negotiations of the story’s details, possible alternatives, or variants. It is way more difficult to modify an exisiting solution proposal into the best one the group could come up with than developing that from scratch.

Continuous collaborative learning is one of the fundamental principles of Agile. We're trying hard to get rid of big up-front design because we believe that group decisions based on the most recent learnings and changes in the project’s environment beat a single mastermind’s plans every day. Let’s do the same with small up-front design, for the same reason.

I therefore propose to strictly develop all User Stories collaboratively between the Development Team and the Product Owner. The PO’s preparation of the Sprint Planning meeting (or separate estimation meeting) should consist in a pre-ordered list of “As a …” phrases. Everything else must be found as a group.

Tags:

About the author


Comments [6]

david, 08.07.2012 19:27 CEST

i see one big risk with this: the PO still needs to know the needs of his stakeholders. collecting this into the story will make him aware of that.
also, when working with external designers, you can't expect to have the designers in the sprint cycle. so either you do the design afterwards leading to duplicate effort and not-really-finished stories. or you have the design before the sprint, but indeed there are quite some aspects that get defined by the design and would no longer be flexible for the team to decide.

Lorraine, 09.07.2012 01:20 CEST

The great thing about user stories is that they don't outline the proposed solution - so not sure I understand your statement "It is way more difficult to modify an exisiting solution proposal into the best one the group could come up with than developing that from scratch."
But I think what you're really trying to say is that it shouldn't be just the PO's responsibility to put together the acceptance criteria - and I couldn't agree with you more there! The whole team should do this together.

Lukas, 09.07.2012 15:39 CEST

Timo, thanks for your thoughts.

How does that fit in with your UCD / UX initiatives? Shouldn't user stories be based primarily on user research instead of involving the dev-team to write them?

steve.holyer, 09.07.2012 16:15 CEST

I think there's a lot of power in the last clause of a user story. The "so that I can" clause. Interestingly I see a lot of stories that leave this off. Cause, "d'uh the "so that I can" is so obvious." Except in that case I think you usually have the wrong user story.

I think that helps to answer @David's first concern. The needs of the stakeholders can--and should--be summarized in the "so that I can" clause. It also helps the team figure out the definition of done. It's done when the user can ...

timo.bezjak, 09.07.2012 16:51 CEST

Lukas, imho User Stories should primarily be based on what has been learned (and achieved) so far during the project. Any UX decisions must therefore be found within the team.

In many cases the team will need support from a UX specialist, just as they may need support from someone who knows a lot about a particular database or library. The specialists themselves will have to learn from the project, too, so they have to be involved as closely as possible.

Peter Gfader, 06.09.2012 10:55 CEST

>>I therefore propose to strictly develop all User Stories collaboratively between the Development Team and the Product Owner.
>> The PO’s preparation of the Sprint Planning meeting (or separate estimation meeting) should consist in a pre-ordered list of “As a …” phrases.
>>Everything else must be found as a group.

I don't know how this is different than that what the Scrum Guide already says.
Search for "Grooming",

Add a comment

Your email adress will never be published. Comment spam will be deleted!