In this episode, consultant and author James Robertson helps us to break down user stories into smaller, more manageable pieces.  He also shows us how to look critically at user stories to make sure they don’t specify a solution.

James Robertson

James Robertson

Co-founder of The Atlantic Systems Guild

James Robertson is a consultant, teacher, author, and project leader whose area of concern is the requirements for products and the contribution that good requirements make to successful projects.

He is the co-author of the best-selling book “Mastering the Requirements Process, Third Edition”, which provides guidance on finding requirements and writing them so that all the stakeholders can understand them. He also co-founded the Volere approach to requirements engineering.

After listening to this episode, you'll understand:

  • How to get started with user stories
  • How to break down large, high level stories
  • How to look critically at user stories
  • Why the second best user story may be better

Show Notes

We often see people creating initial user stories and then treating them as if they are cast in concrete.  Instead, think of user stories as an opportunity to explore the real need.  Think of agile development as two parts; discover and deliver.

Use the story to discover the real need.  Start by think of it as not a user story, but as a story of a need.  Using “I want” in a story sometimes leads us to prematurely identify a solution.  To instead focus on the real need, switch to “I can”.

After the story is initially written, it needs to go through processing or refinement.  The initial story does not need to be written so as to fit in a single iteration.  It can be later refined and right-sized.  Focus on the business or user need and keep the stories high level.

After you have the initial story, you can refine and split the high level story (epic).  One way to do this is to look at the user role to identify if there are different roles that have a similar need and split the stories based on that more detailed role.  The key is to make sure the epic is the right story.

The most common format for a user story is: As a <role>, I want <need> so that <goal>.

When you look critically at the user story, make sure the role is valuable to the organization, the need is truly a need and not a solution, and that the goal is valuable to the role.  Look for the second right story; the story that digs deeper to discover the real need.

Often, people assume that they know the answer.  Challenge assumptions to find a user story that expresses the real need and allows software engineers to find the right solution.

 

Z

Your Homework

1. Don’t write stories starting with “I want” because that leads you to a solution. Instead, start with “I need” or “I can”.
2. Look for the second right story. Look critically at your user story and identify ways to improve it.
3. Don’t forget non-functional requirements. Review your user stories to make sure and non-functional aspects are identified.

What’s your take?

What do you find challenging about User Stories?  Please share your experience and comments in the section below.

 

Links mentioned in this episode:

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.