How we handle user stories and close them.

Published on 11 November 2016

It’s easy! You just write a user story give it to a developer and let him do his thing and afterwards test it. No big deal right? Well in general that’s pretty much it, but when it comes to the details the problems start to uncover. I am a software developer at PBS and here is how we handle a user story from start to finish.

 

The hard part

Creating a user story sounds easy but is by far the hardest task of the whole process. It’s often difficult to understand what the customer really wants. The specification goes through various instances and tiny changes happen, these changes happen constantly and obscure the original idea. We have to carefully evaluate the main points and interpret how the customer wants the product to be. After this step a user story gets the state “Draft”.

 

What every manager wants to know

After all that hard work our requirements engineer presents the User story to us and we evaluate any further open questions. This step is repeated until no questions are left unanswered.

After accepting a user story it’s the whole teams turn to make the managers happy by estimating a relative size of a given user story. That not only helps us plan our sprints and commit to a workload, but also helps our managers in their planning process. A round of planning poker helps us decide. We finalize this step by giving the user story the state “Specified”.

 

Getting it done

Now it’s time to program! After all we’re software developers and that’s our time to shine. Our developing process consist of 2 major steps: Developing and testing. Developing can be done in multiple ways. We often just take the user story and start developing on our own. Exceptions can be user stories which need to alter critical parts of the code where we often use pair-programing techniques to ensure nothing gets broken in the process.

One of the newest additions to our repertoire of development techniques is what we call the “Three Amigos” where a short term team of three is created. This team consists of one developer, one tester and one stakeholder (often impersonated by either our requirements engineer, our product owner or our designer). The user story which is done by those three amigos has the highest priority for that team and goes from start to finish in a way higher pace. After the development is finished the user story gets the state “Resolved”.  We then start to fill out a form where we explain any new parameters we created in the process, explain the steps we took during implementation and finalize our development work by giving the user story the state “Documented”

 

The testers take over

Every story that has the state “Documented” is ready to be tested. Our testing team then starts to look at the acceptance criteria and creates test cases accordingly. Every test case consists of prerequisites that have to bet met in order to test the user story, several test steps and an expected outcome. When all of those test cases are done (this can also be done prior to development as the acceptance criteria don’t change after a user story gets the state “Specified”) the testing can start. The testers use several different hardware configurations to test the story and its acceptance criteria. To wrap it up the tester writes down which hardware and software version was used and if the tests passed. The user story now gets the state “Tested”.

 

A party!

Only one more step to finally complete a story. This has to be celebrated. Now comes what we call a “Closing Party”. When multiple user stories arrive at the state “Tested” a small meeting is organized, where some testers some developers and the requirements engineer are invited to look over all of the tested user stories and approve, that the user stories meets all of their acceptance criteria, one last time. All accepted user stories finally get the state “Closed” and can be rolled out in the next release.

 

The journey is over

As you can see there is more to completing a single user story than meets the eye. It’s the little details that make the difference. I hope you enjoyed our little journey of a user story from start to finish and wish you a pleasant day.

 

What is your opinion about the topic?

I’d love getting some feedback from you – please write a comment or send an email!

Yours,
PBS-Blogger

Leave a Reply

Your email address will not be published. Required fields are marked *

Register for
our Newsletter