User Stories - The start

User stories are the thing that keeps me busy these days. Identifying them, splitting them up and putting them in our Team Foundation Server where our backlog resides. I’ve decided to do a series of posts about them, because for me it was a quite a switch from the usual more formal requirements engineering approach.

A users story

So what is a user story. It’s nothing more then something a user wants and will create value for him if it was finished written down somewhere. Something a user mentioned and decided that it probably would benifit him. The software development team would write it down somewhere and leave it there.

Don’t think it’s a requirement at this point because you never actually talked about the user story to see what the user really wanted and how it would be built. It’s only a reminder for you to talk with the stakeholder sometime. Mike Cohn always talks about the 3 C’s as a reminder to what a user story needs to be. A quick resume:

Cards
Use a dead simple approach in documenting the user stories. Nothing more than a card will do.

Conversation
Details about the story will only come out when we talk with the stakeholder.

Confirmations
A checklist of statements which tell when the story is completed. This evolves when you are talking to the stakeholder.

Something which is not really clear in these three statements is wat what point in the process the stories are “complete” for certain steps in the software development process. So how did it feel for us when we worked with user stories?

User stories as a reminder
Some stuff mentioned by our stakeholder was stuff we could imagine adding value for him. We wrote it down on a story card and left it there. We stopped talking about it because we also noticed it hadn’t any priority compared to our other user stories although there were lots of questions you could ask about it.

In our discovery sessions (our first conversations with the stakeholders) we also put this as rule. We would only identify stories and not talk about them in detail. Next step was to order the list of user stories by thinking about the priority of them.

User story slicing
So we identified the stories which were important. Asking the developers about the size of them they told me it was not anywhere near buildable. Now what? We did a user story detailing session. What stuff could we identify belonging to a user story and could be build seperately according to our stakeholder which would still bring value for him? An example of what a user story would become:

Our high level story

• As a Support employee I want my client to send in a certificate request by filling in a digital form so the data can be checked in a webform and send in digitally without any writing recognition difficulties.

Which resulted in some of the below user stories

• As a Support employee I want a check on the certificate request form to check if the client has a contract with us so that I don’t have to do this again when I receive the digitally filled in form
• As a Support employee I want a webform so that the clients can send in a certificate request digitally so that I don’t have any difficulty recognition the clients hand writing

So now we sliced up our user stories and the developer told us that it was more granular now but he still needed some more confirmations on when then webform would be finished. What fields would there be on the webform. How did we imagine the webform to be delivered to the Support employee. We added those to the confirmations of the story so the developer would know when it was finished.

The status of the user story? It was detailed enough for the developers but (!) it still is a reminder we need to have a conversation with our stakeholder to figure out what the webform would look like. What the order of the fields would be, etc. But the impact on the developers time is within margins.

A quick introduction of how we did it. In the next posts I will digg a bit deeper in the techniques we used for identifying which user stories to plan for a sprint and good habits how to describe stories, verifications and what the real benefits are. Because in the process you feel it is faster and better, but we need to make this more concrete.

Question to the audience. Anyone can guess what the image is representing?

Share this