How to Explain and Present User Stories

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Askshutterstock_193558859

When I coach teams and their product owners, one of the first areas I want to help them correct is the backlog refinement sessions.  Most of the time these are hours-long grueling meetings where the teams are wondering, “Why can’t we just go code?”  Just like many things, the pain that people feel in a new process is because of inefficiencies upstream.  In this case, the product owners often have no idea how to present the information to the team to be able to size, refine, split, and ultimately deliver the story.  In this article, I will explain “How to Explain and Present User Stories.”

Step 1:  Present the background and business case

A big mistake I see product owners make, especially with new teams, is to jump directly into reading the story to the team without giving background.  In the case of a project that already has some momentum, this us understandable.  You certainly don’t want to reinvent the wheel.  However, for teams that are starting out a new project, it is very important that you present the background and business case associated with this project.

Presenting a background and business case does not mean reading a 40 page MRD or PRD to the team.  It means helping them understand the problem from a big picture perspective and the solution to fix the problem.

Step 2:  Present the problem and feature area

Problems that are big enough, complex enough, and important enough to require a software team generally have “sub problems” associated with them.  These sub problems have feature areas to solve for them.  The sub problem and feature area are important because its another step down in granularity.  This gives additional context to the conversation.

Step 3:  Present the user story and acceptance criteria

Now is the time to present the user story, which is fine, because the team has mental boxes to put it into:

  • What is the big picture problem we are trying to solve
  • How have we decomposed that problem into smaller problems
  • What is the specific small problem we are trying to solve with this user story in particular
Reminder:  When you present a user story, make sure you have a clear idea of who the user is.  Use personas to outline basic information about your different user types, such as age, pain points, general goals, and level of comfort with technology.

As you present the user stories, you will also need to present the acceptance criteria for the story.  Invariably, the team will have questions about the acceptance criteria, specific use cases, and other scenarios not outlined in the user story.  Make sure you (or your Scrum Master) update the story with this additional information.  The conversation is the most important part of a user story.

Step 4:  Ask the team if they have enough information about this user story to size it

The first couple times, the team will be taken aback at the directness of this question.  But this question is very important to the progress of the meeting.  As new stories and requirements are presented, sometimes the conversation degrades into an architecture discussion, or a trip down memory lane reminiscing about the last time they developed a similar feature.  This is fine, but left unchecked, the conversation will go on forever.  So you will need to ask the team every so often “Do you have enough information about this user story to size it?”  If they don’t, your next question should be “What else do you need to know about this user story to be able to size it?”  Continue to ask this until you get a reasonable size.

The big picture

As I always like to say, “Context is everything.”  The difference between how I suggest product owners present user stories and how its done in real life is that my method gives full context.  If we want to leverage the collective brainpower of the team, everyone needs to understand what kinds of problems we are looking to solve, for whom, and what is the business impact.  That will enable us to make smart decisions and tradeoffs when it comes to delivery.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Write User Story Acceptance Criteria

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask

[activecampaign] Tirrell Payton on LinkedIn Payton Consulting Facebook

When I am working with my clients who have already started adopting Agile, one of the first item I look at is their backlog.  Why?  Because the quality of the backlog is a leading indicator to how well the team will perform.  Unfortunately, most backlogs created by beginning product owners are in no shape to be consumed by a team, and the number one reason for this is usually a lack of acceptance criteria in the user stories.  In this article, I will talk about:

What are acceptance criteria?

Acceptance criteria are statements of requirements that are described from the point of view of the user to determine when a story is “done” and working as expected.

This helps the team reduce risk by testing against the same criteria that were agreed upon when the team accepted the work.  Acceptance criteria are emerging and evolving and assumed to be flexible enough to change until the team starts working on the story.

Anyone in the team like business analysts, QA and developers can help the PO in both creating and reviewing the acceptance criteria.

Advantages of Acceptance Criteria:

  • Triggers the thought process for the team to think through how a feature will work from the end user perspective
  • Helps the team to write the accurate test cases without any ambiguity to understand the business value.
  • Eliminates unnecessary scope that will add no value to the story, in other words, it will keep the right content.

Example of a User Story With Acceptance Criteria:

Customer would like to have an email sent to my normal email address when his account goes into overdraft so that I know that I need to put money into my account.

Acceptance Criteria:

Input

Process

Output

Valid Email Address Email Validation Message sent to email address
Invalid Email Address Email Validation Flag online profile as incomplete, kickoff snail mail message.
Valid Email Address Marketing Messaging Marketing message copy matches copy provided by marketing
Valid Email Address Marketing Messaging Marketing message design matches the specs provided by marketing
Valid Email Address Marketing Messaging Message contains email link that allows the user to navigate to online banking
Valid Email Address Email Validation Message sent to email address

 

In the above example, Acceptance criteria are a set of statements that represent the requirements “conditions of satisfaction”.  It also contains boundaries and parameters that determine when a story is completed and ready for acceptance. It expressed clearly in simple customer language without any ambiguity on what is expected as outcome. It must be easily actionable and translated into one or more manual/automated test cases.

When the development team has finished working on the user story they demonstrate the functionality to the Product Owner, showing how each criterion is satisfied.

Creating Acceptance Criteria

Acceptance criteria consists of 3 parts: input, process, and outcome.  A useful way to think about acceptance criteria is:  “When I <input> X  and <process>Y, I will check for <outcome>Z as the result”.

The inputs of acceptance criteria are things like “entering a value and pushing a button” or “entering a command and checking results”

The process of acceptance criteria is the actual computation being checked.  Usually when we create a user story, we want something to happen for a given set of inputs by a user.  That process, while not usually directly observable, is verifiable for a given set of inputs and expected outputs.

The outcome (results) of acceptance criteria should always be testable with minimal ambiguity.

When people think about user stories, they usually think in terms of the user story description.  However, the user story is not complete until it has verifiable acceptance criteria.  Acceptance criteria also help the team quickly size a user story, because once they know how the story will be verified, they understand they effort needed to make it happen.  Use acceptance criteria with every user story.

[activecampaign]
There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Create User Stories from Traditional Requirements.

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Askshutterstock_172355312

When I coach teams, many times, my attention goes to the requirements analysts, because they feel discomfort trying to understand the difference between a user story and traditional requirements. I was talking to a requirements analyst last week, and he was complaining, “My company started to go the agile way, and I was told to write requirements as user stories. I have no idea on how to write user stories. Do we still need requirement documents? I see the concern expressed is one of the most common one that makes people nervous.

It is hard to figure out
how to break the big requirement specifications into smaller chunks of work doable in iteration.  Here are few tips and tricks that help to slice the big requirements documents to user stories.

Traditional requirement documents have features specified by each module or milestone.

shutterstock_226347637

Tip1: Pick one feature at a time and prioritize

Take each module or big feature from the traditional document, and understand

  • Who is the user of that functionality
  • What is the purpose of that requirement
  • Why does he need that functionality

The “Why” in the last point will tell you the actual business value the end user gets from the feature. It also helps you to assess whether the end user really needs that feature. If you see that there is no real business value in building feature, then push it to the bottom of the stack.  The aim is to identify the most important big rocks that are useful for the end user to build his system.

shutterstock_167285585

Tip 2: Break the big feature into small chunks

Now this big rock cannot be obviously built in a 2 weeks or 4 week iteration. It needs to be broken down into smaller pieces.  Start splitting the requirements into smaller pieces. As you identify each smaller requirement, try to come up with the functionality aka the acceptance criteria that tell us whether we are building the right feature.

shutterstock_157384295

Tip 3: Support it with other artifacts

One myth that many have in their minds is that a user story and acceptance criteria is only a bulleted list of sentences.  However, that is not true.

While writing the user story and acceptance criteria, it is Okay to support it with all additional artifacts that are needed. For example: any wire frame, business rule document, any architecture diagram etc. but ensure you attach the bare minimum things without investing lot of time and the developer understand the intent of the story.

Tip 4: Make sure the requirements are clear

shutterstock_140339647

  • Ensure that conditions of satisfaction for each story is identified aka the acceptance criteria; That helps the team build the right functionality.
  • Write down the tests that can be run verify whether the right functionality is really implemented, aka the acceptance tests, that confirm the acceptance criteria is met. Running these acceptance tests would qualify the story as a DONE and accepted story by the end-user.
  • Map dependencies across the stories and have them specified in the same user story for reference. As an example, the “send email” story is dependent on “create email” story.  Ensure the top level feature is outlined, i.e the big rock, so that we know what we are looking for once all the user stories are created.
  • Outline any assumptions around how will you demonstrate the small rock to the end user, for example any test container that you may want to use until the actual test environment is ready.

 

Tip 5: Repeat and rinse

shutterstock_205094437

Repeat all the above steps until a feature in your traditional document is covered.

Decomposition is the same, you are just making it outcome driven instead of activity driven

To summarise, take the a big requirement specification document, break it down into feature, break it down into smaller requirements, prioritize them, take the most important ones from top of the stack, capture enough details in the form of acceptance criteria aka the condition of satisfaction. This way you are nailing down on the most important requirements, releasing them to team early to build them, so that ROI can be realized faster.

 

Do you think this way of breaking the big rock into smaller ones, and building them is better than building the bigger rock at one go? Of course I agree that, there is a need to integrate back all the smaller pieces.

 

 

 

 

 

 

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Create a User Story

User stories are simple to understand yet take a little time and practice to master.  So today, I am going to show you how to create a user story.

A user story is a way to describe WHO wants WHAT and WHY.  As opposed to representing all the facts round this required functionality, its primary purpose it to serve as a conversation starter so that the people who will be implementing the functionality understand the full context.

A user story is a convenient format for expressing the desired business value for a feature told from the perspective of the person who wants the feature, usually a user.

In scrum, user stories are one of the best and most popular form of creating a shared understanding of what the user of a system wants to accomplish

The user story consists of 3 parts

  • Card
  • Conversation
  • Confirmation

Part 1:  The Card

The “card” is a high level description of what the user wants, usually taking the form of “As a <type of user> I want <some functionality> so that I can <achieve some kind of goal>” or the form I prefer “<type of user> wants <functionality> so <reason>”

Part 2:  The Conversation

Since a user story is the promise of a future conversation, the “conversation” part of the user story is just that; a conversation around what the user wants and the goals the user wants to achieve.
The purpose of this conversation is to create a shared understanding of the expected outcome of implementing the story.

Part 3:  The Confirmation

The “confirmation” is the additional detail captured during the “confirmation” that confirms the details, expected outcomes, acceptance criteria, or anything else that was discussed and agreed upon during the conversation

Story Details and Acceptance Criteria

A user story is not complete without acceptance criteria.  Acceptance criteria provide boundaries around the story so we know what specific items we can verify against to ensure the story is done.  Acceptance criteria also provide a way to validate shared understanding exists between the requester of the story and the implementer of the story.

Example of a User Story with Conversation Details and Acceptance Criteria

Description:  System administrator wants to select folders to be backed up so the backup system does not save un-needed files

Conversation Details
– User should be able to select any folder in the system
– If there is a backup in progress, folder selection is locked
– Folder selection should be under “settings”
– Folder selection should be the standard windows directory tree view
– A folder that has been previously backed up then deselected will be purged from the backup system

Acceptance Criteria
– Verify the user can select/deselect folders at will
– Verify the folder selection is locked when there is a backup in progress
– Verify the folder selection window is the standard windows directory tree view with checkboxes
– Verify the unselected folders do not backup on the server

 

[activecampaign]
There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Prioritize User Stories

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Askshutterstock_178631474

His face was stern, and his voice had an air of seriousness, “I don’t think you quite understand.  In our business, everything is priority.”

If I had a dollar for every time I heard this, I would be a very wealthy man.  Yes, everything is priority.  Everything is always priority because you have a large group of stakeholders and they all want their stuff first, thus everything is priority.

Realistically, you can not get everything done all at the same time, so even though “everything is priority”, some things will come first, and some things will come last.  A softer word for priority is “order”, but in this article I am going to show you how to prioritize user stories.

Option 1:  Prioritize by Knowledge Value

At the beginning of a project, what you don’t know might hurt you.  Removing the unknowns is a huge opportunity to positively impact the health of the project over time.  In order to prioritize on knowledge value, we have to be willing to admit we don’t have all the answers to the unknowns.  After we do that, we can prioritize some of the “knowledge value” items on the backlog, such as spikes and prototypes.

Option 2:  Prioritize by Increased Revenue

This one is always a clear winner, but is heavily dependent on the sophistication of the product owner to be able to articulate the ROI associated with a feature or user story.  Therefore, this needs to be one of the items thought about when prioritizing.  An example of this would be payment options.

“15% of our revenue came from Paypal in the last version of this product, so it stands to reason that 15% of our revenue will continue to come from Paypal.  On the other hand, only 5% of our revenue came from ACH debit, so the Paypal functionality will be prioritized higher than the ACH functionality.”

Option 3:  Prioritize by Reduced Cost

This is another one that is easy to articulate and easy to defend, but requires some research and number crunching to have a sound basis.  Cost reduction or reduction of “Total Cost of Ownership” is usually one of the driving forces behind new projects.  An example of cost reduction would be changing platforms:

The old platform costs 10c per transaction, and the new platform costs 7c per transaction.  Moving the functionality to the new platform will save us 30% per transaction, and we do over 1 million transactions per month.

Option 4:  Prioritize by Reduced Risk

There are all kinds of project risks to keep in mind:  Technical Risk (can this be done?), Social Risk (can these people do it), and Execution Risk (will the marketplace accept this?).  Items in your backlog that can point to a reduced risk can be prioritized according to the magnitude and likelihood of the risk itself.  Here is an example:

The state fines us a surcharge depending on how accurate our claims payment processing is.  This functionality will reduce claims errors by 30%, reducing the risk of non-compliance.

Its always a guessing game

Prioritization is always a guessing game, and you have to find the balance between getting a perfect priority and being flexible enough to let the work emerge.  Don’t ever expect to get a perfect priority.  Some stakeholders will always be unsatisfied with how it was done.  As long as you have a framework to guide your thinking, you can defend the choices when asked.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Scrum Documentation: User Stories: What it is and how to create it

A user story is a convenient format for expressing the desired business value for a feature told from the perspective of the person who wants the feature, usually a user

shutterstock_209774098

In scrum, user stories are one of the best and most popular form of creating a shared understanding of what the user of a system wants to accomplish.

User stories consist of 3 parts:

  • Card
  • Conversation
  • Confirmation

The “card” is a high level description of what the user wants, usually taking the form of “As a <type of user> I want <some functionality> so that I can <achieve some kind of goal>”

Since a user story is the promise of a future conversation, the “conversation” part of the user story is just that; a conversation around what the user wants and the goals the user wants to achieve.

The purpose of this conversation is to create a shared understanding of the expected outcome of implementing the story.

The “confirmation” is the additional detail captured during the “confirmation” that confirms the details, expected outcomes, acceptance criteria, or anything else that was discussed and agreed upon during the conversation.

For more information on user stories, click here.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

What needs to be in your user stories’ definition of done

shutterstock_122571565

Harvey Ball said:

I’ve seen many team’s definitions of done, more and more I’m seeing teams include a list of test types that need running to ensure a story is done.
Example: * Unit tests written and passed * Service Integration tests written and passed * Performance tests written and passed * UI Tests written and passed ..etc..

I’ve always considered the definition of done to be generic enough to allow it to apply to any story a team may work on so it seems a bit too detailed to me to list all possible test types.

Perhaps if you list all the tests and you have a story that doesn’t require a test (such as you have a story that has no UI, then how do you write a selenium or equivalent based test?) then how can it pass the definition of done?

Or maybe you have a story that requires a specific test type that you don’t have on your list? Maybe a vertical access test? Because it’s not on the list, no one ever thinks to raise it?

I’ve always found the topic of how to prove a story is tested should be discussed at the sprint planning phase and the team work out which are the appropriate tests to ensure the story has a high confidence in quality.

This blog post by Mike Cohn has a good example of what I like to see in a definition of done:
http://www.mountaingoatsoftware.com/blog/clarifying-the-relationship-between-definition-of-done-and-conditions-of-sa

Something that is meaningful but also something that isn’t so tied to specifics that you can’t meet it or in meeting it means you miss something out.

I’d be really interested in other people’s views on this and to see if there are valid reasons for listing multiple test types in the definition of done.

=====================================>

Hi Harvey,

The list of test types, especially if they are repeated for EVERY STORY, should be added to a master list called, “organizational standards”. Then, for every story, you can simply put “… and meets all organizational standards where applicable.”

The definition of done should be focused on those verifiable DIRECT VALUE ADD ways we can empirically prove this story is done. The testing types are not a direct value add, and while they are important for a number of reasons, they should not be the primary focus in the definition of done. Hence why I suggest companies add them to their organizational standards and reference them. Why? Because they will most likely be repeated in every single story.

Let’s take a look at a more meaningful mock story and mock DoD:
“As a user, I want to be able to use a single search field to search by title OR author OR ISBN (like I can on Amazon)”

Definition of Done:

  • When I search for an author, such as Salinger, I get Catcher in the Rye
  • When I search for a title, such as Shakespeare, I get titles such as Romeo and Juliet
  • When I search for an ISBN, such as 0736425152, I get a book about Wall-E. User story meets all organizational coding standards.

In short, don’t turn the DoD into a lawyering document catch-all. If you have certain types of tasks that are repeated, such as writing unit tests, ui tests, integration tests, checkins, deployments, etc, those should be represented as tasks in the story and as “organizational standards of done-ness that apply to all stories where applicable”<-this gets you around the fact that headless components don’t need ui testing with Selenium

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Question of the Week: How many people should be involved in writing user stories?

I’m in a large project that’s writing user stories now. We have the product owner, the business analyst, and 3 senior developers (including myself) holding round-table discussions on each story. It’s actually turning into long, slow product redefinition. We would move faster if fewer people were involved in writing the stories and the entire team convened to assign function points and challenge the handful of stories which pose some difficulty. But is there a good reason to keep the round-table format?

Any and everybody can and should be involved in writing stories: Product Owner(s), Scrum Master(s), Team, Stakeholders. The person writing the story should have a discussion with the PO to explain why that story is important.

The technique that limits the amount of churn is that the Product Owner should be the person with “Content Authority” over the final say in terms of priority.

  • Why are you holding round table discussions on each story?
  • How many stories are you finishing per sprint (if you are doing sprints)?
  • Do you have a product owner (or person with the final say on prioritization)?
There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Write User Stories for Bugs

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask

I was finishing up a week of training with one of my clients, and by all accounts, it was a stellar week.  People were excited and motivated to jump head first into Scrum, and the product owners were excited to start writing stories.  One of the tech leads came up to me and said, “What about bugs?” “What do you mean?” “I mean, do we write user stories for bugs?” “If you want to.  Its not absolutely necessary, but if you have 10 minutes we can chat about it.”

shutterstock_218921119

Should a team write user stories for bugs?  You should do this only if expressing the bugs in user story form has value. User stories are useful but not always necessary.

On Defect Management

Defect management is one of the areas where companies tend to trip over themselves trying to figure out “How agile says we should do it.”  Take a step back from the process and look at the goal.  The goal is to deliver working software that fulfills customer needs.  In a lot of cases, administrivia is a non value add but necessary component of delivery.  We want to minimize this where we can, and when we can’t minimize it, ensure that it has value.

So instead of asking, “Should we write bugs as user stories”, ask yourself, “Would writing bugs as user stories add any value to us delivering software to our customers.”

When you frame this question, and a lot of other questions in this manner, the answer becomes obvious.  Even if you pick the wrong answer, you can always retrospect and change it.

Bugs as User Stories

So in this article I will show you how to write user stories for bugs, should you decide to go that route.

Each bug report should be considered its own story, especially if fixing the bug is likely to take as long as a typical story (2 days or so).  For bugs that are minor and can be fixed quickly, these can be combined into a single bug story.

Step 1.  Use “Without” in your user story description

Example:  Administrator would like to log in from a mobile device without having the admin panel squished together and illegible.  What this does is outline the behavior you DON’T want (the bug) from the perspective of its impact on the user.

Step 2. Outline “Steps to reproduce” in your story details

This reiterates the conditions that will help the developer understand how to create the bug and helps with testing.

Example:  Administrator would like to log in from a mobile device without having the admin panel squished together and illegible.  What this does is outline the behavior you DON’T want (the bug) from the perspective of its impact on the user.

  • Using android or iPhone, log into the admin panel
  • Expected result:  responsive panel
  • Actual result:  squished panel (unusable)

Step 3.  Invert story description in your acceptance criteria

Example:  Administrator would like to log in from a mobile device without having the admin panel squished together and illegible.

  • Using android or iPhone, log into the admin panel
  • Expected result:  responsive panel
  • Actual result:  squished panel (unusable)

Acceptance Criteria

  • User can log into the admin panel on a mobile device and it will be usable
  • The admin panel will accommodate various screen sizes
  • Report viewing will be disabled on mobile, but the user has the option to send a pdf to their email

A view from the field

Some teams like to write their bugs as user stories, and others don’t.  Like nearly everything, it depends on context, environment, industry, company size, and a lot of other variables.  What about with your teams?  Do you write stories for bugs?

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More