User Stories in Practice

716 0

I’ve been working with software development teams over the past 10 years. In different roles I’ve gathered software requirements for writing business requirement and functional specification documents. During this time, I’ve experienced the transition from waterfall software development to agile software development.

Once my requirement documents were finished, development could start. Following a linear approach like waterfall. I assumed wrong that I wrote my documents first time right. Lots of requirements needed to be changed during development and my documents had to be updated. Long hours of rewriting followed, reminding me of what an inefficient way of working that was.

Even though I was aware of user stories, I wasn’t able to successfully put them to use. My eyes were opened when I started working agile following SCRUM. With more interactivity, more feedback loops, I started to see their benefit. User stories proved their value as they are easy to comprehend and helped defining and adapting requirements. Planning improved too, the actual gear was put in place to shift the car, with artifacts such as the product backlog and sprint backlog introduced by SCRUM.

 

What are User Stories?

User stories are short sentences, including a description of new functionality, written from a perspective of a person desiring it. The following pattern is used:

As a <user>, I want <goal> so that <reason>.

A large pile of user stories provides you a good overview of stakeholders and high-level requirements.

 

Key benefits

Keeps the User Central User-oriented user stories help the team developing functionality for real users. It is not a regular to-do item on your to-do list.
Encourages Creativity Everyone can participate in creating user stories, a good way to get committed and become creative.
Build Momentum Small successes need to be celebrated. The completion of each user story creates a good momentum for the team.

 

Story Slicing and Splitting

The level of detail of user stories can vary. User stories can be written to cover large functionality. This is an example user story from a customer portal web site:

  • As a user, I can request support to be assisted with my question/problem.

Requesting support should be possible via a FAQ, chat and a contact form. In agile software development it is intended to finish a working increment of software at the end of each sprint. This story is too large. Large user stories are known as epics.

Epic user stories need to be sliced. They need to be split into smaller user stories:

  • As a user, I can request support via chat, to be assisted with my question/problem.
  • As a user, I can read common questions in a FAQ, to be assisted with my question/problem,
  • As a user, I can get in contact filling a contact form, to be assisted with my question / problem.

Story slicing is a practice for which Alistair Cockburn invented a nice exercise called Elephant Carpaccio.

 

Acceptance Criteria

Acceptance criteria determine if the user story is successfully completed and work as it was intended. For one of the above examples you could include:

  • A user must be able to identify the person he or she is chatting with.
  • A user can see its number in the queue when waiting for an open slot.
  • A user is notified when there is no support available outside office hours.
  • A user is automatically asked to fill in a survey based on their chat experience.
  • The average waiting time for an open slot is recorded.

 

Working with User Stories

Adding User Stories

Anyone can add user stories to the product backlog at any time. The product owner is responsible for the product backlog but is not necessarily the one writing user stories.

Detailing User Stories

User stories are very practical when it comes to feedback loops. User stories are very lightweight. Everybody can read them in an instant and interpret them in their own way. Details / Requirements can be added to the user story while it is still on the product backlog. During the team refinement session it is determined by the team whether the user story is ready to be planned in a sprint.

Estimating User Stories

The team adds story points to user stories. Story points are a size indication to determine how many user stories can fit in a sprint. The team capacity should, of course, be taken into account at the start of the sprint planning. Reading Estimate a Story gives you a better understanding of how to estimate user stories in practice.

Prioritizing User Stories

It is the product owners responsibility to prioritize user stories for each sprint. Using user stories in combination with a product backlog makes it very easy to plan user stories for each sprint.

User stories are not Tasks

Detail your user story accordingly. Create subtasks within the story making sure the user story can be developed efficiently. Be pragmatic.

 

User Stories versus Use Cases

The two can be mistakenly compared, them being ways to document requirements. In my opinion user stories do not replace use cases. User stories are great to drive development. But when you end up with a large list of user stories, it’s hard to visualize their relationship. Detailed requirements are spread across many different user stories.

Use cases can be seen as long-term documentation that after development, should always reflect the actual state of the software.

Tip! If you detail your user stories as you are writing use cases, it is fairly easy to incorporate it into your use cases.

Lessons Learned

What I’ve learned is that user stories are a great way to increase collaboration. They are great for planning and working out details (together). I was able to spend more time with stakeholders, improving requirement quality. I no longer had to update documents all the time. Participation of colleagues and their commitment to the project increased. And information was shared effectively using digital scrum boards. Working with user stories was a big win for everyone.

Leave a Reply