How to Run a User Story Workshop

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

Running a hands-on user story workshop is one of the most valuable skills a product owner can learn.

7 Steps to a successful User Story Workshop

Step 1:  Form a group of 3-5 people who understand the purpose of the product

3-5 seems to be the magic number. Any less and you might miss some ideas.  Any more, and it slows the process down as well as diminishing returns on the quality of ideas generated.

Let the team to come up with a vision of own dream product. Propose to them that they write high level features for the vision. Clearly explain what you mean by a feature. (Example: Login page for a portal is not a feature). Take each feature and identify the high level requirements on color sticky notes.

Step 2:  Introduce the phrase “EPIC” and tell teams to break features into epics in different color sticky notes

Make a wall map and help the teams to paste the epics exactly below the features. When teams establish features and epics relationship, I would work with them to make team write high level requirements for each epic. Introduce User Story with an example and its intent. Help teams understand various formats of User stories. Convey the importance of identifying User Personas at this stage. Show some examples of splitting user stories. Give few guidelines of dos and don’ts as well as pitfalls and traps when writing user stories.

Step 3:  Start the exercise by asking teams to write high level one liner as requirements for each epic in silence

Each person takes the same colored post-it and silently writes down one user story per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud. If anyone has duplicates, consolidate.

Depending on the size of the epics it can take 3-10 minutes to get all the major user stories. You can watch the body language to see when teams are finished. You can observe that the group goes from huddled in at the beginning to standing/leaning back at the end. It is likely that each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc) which forms the “walking skeleton” of the map. Ask teams to stick all user stories exactly under the related epics. This might be their first ‘aha’ moment for silent brainstorming.

Step 4:  Ask the team to group the sticky notes in silence.

Ask team to move similar things close to each other and dissimilar moved farther. Use silent grouping  because it is faster than grouping them out loud. If duplicates are found, remove them. Groups will form naturally and fairly easily. Once again, body language will help you see when they are done – usually 2-5 minutes.

Step 5:  Introduce acceptance criteria with an example

Help teams write acceptance criteria for individual stories. Now talk about the non-functional requirements. Ask the team to come up with non-functional requirements for the same stories. Arrange all the stories on the wall, and help teams order them, ask them use slice the stories either by date or scope.

Step 6:  Explain sizing of stories using story points and help teams size all the stories

The product owner explains the sizing constraints and facilitates a  story points sizing exercise using planning poker with the team.

Step 7:  Take all the user stories into the first release, then start slicing stories to make them as thin as possible

This is so that the stakeholders get a solid understanding of vertical slices, and so that we will more accurately be able to measure progress.

I see there is lot of value and motivation when team s to come up with their own vision and write down the stories.  The essence of the workshop may be lost when I give pre-cooked user stories to the team. What do you think?

 

 

 

 

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

Read More

How to Groom, Group, Manage, and Organize User Stories

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

 Very often, I observe team members conversing in retrospectives, “we have to wait for the requirements to be clarified by the Product Owner, and it is eating up a lot of time and delays our work in the Sprint. In the “good old days” we had requirements specification document which was easily manageable. ”   It is imperative that teams face an uphill task to manage hundreds of stories in their backlog.

I was pondering upon this problem for a while and understood that teams are missing a very important ceremony in the sprint called “Product Backlog Grooming” that would help in grooming, grouping, managing and organizing the user stories.

In short, the product backlog is the single source of requirements in agile, it is an ordered list of requirements, and the majority of the items in this list are the user stories. It needs to be continuously groomed whenever you see a need for it.

Here are few techniques for a team which can make their life easier when dealing with the user stories.

1.  Groom the stories

The teams will have to spend at least ten percent of the time during their iteration, with the product owner to understand the existing stories in terms of clarity, feasibility and fitness in the iteration. If the story is big one, then they need work with the product owner to break it down into smaller chunks, manageable in iteration. Mark the stories as ready for sprint after this meeting, so that there is no back and forth during the iteration.

Remove the stories from the backlog that are no longer needed.

Clarify the stories by elaboration the conditions of satisfaction as required.

Estimate the stories with the best known facts at that time.

Adjust the priority of the story with the permission of the Product Owner. The grooming activity is very much essential to maintaining the product backlog, otherwise it would become unmanageable.

2.  Group the stories

We can group related together under one umbrella that helps us visualize the progress of stories. For example have all reporting templates related stories under ‘reporting’ group, all user management related stories under “user management” group and so on. This grouping of stories is called as “Themes” in agile.

Create high level groups when you start eliciting the requirements and try to group the stories accordingly as and when you add new stories to the backlog.  Some tools like Rally, support a Parent-Child relationship and successor-processor relationship that supports user stories grouping.

3.  Manage the Stories

Managing the stories is very simple. For each story in the backlog, the following attributes that would help in fetching the complete details of the origins of the story, that will make it very easy to track.

  • User Story description
  • Acceptance criteria
  • Parent user story
  • Priority
  • Assumptions
  • Dependencies
  • Assigned to
  • Estimate
  • Team assigned to
  • Group (if this story is grouped )
  • Tasks associated
  • Tests associated
  • Status: Done, In-progress, completed, blocks etc… Impediments etc

Follow the DEEP model, as Mike Cohn calls it. DEEP stands for

Detailed

Appropriately Highest priority, more detail; lower priority, less, which are broken down into smaller stories for sprints/release.

Emergent

Growing and evolving overtime; Re-prioritized when items are added /deleted.

Estimated

The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points.

Prioritized

Items that are slated for the next couple of sprints

Organize the stories

Organizing the stories is easy, have team-specific backlogs. Have the stories that are related to your team only in your backlog. Themes are also used to organize stories for releases.  Link your team stories on which you have dependency with other team, that way, you will come to know the status of other linked stories. Have frequent conversations with the Product Owner to prioritize and reprioritize stories.  Help your Product Owner to remove the stories that aren’t belonging to your team.

Imagine your lawn in the back yard, how do you maintain it? It has to be maintained regularly? If not at some point of time it becomes unmanageable, grows haphazardly in all directions, making it difficult to maintain. Similarly, backlog grooming is not a onetime effort.

Do you think you need to consciously water your lawn, trim and manure it, so that it looks healthy?  If you didn’t, imagine what might happen!

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

Read More

How to estimate user stories

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

Ideal days

Ideal days are the most common way to estimate in traditional project management.  When estimating in ideal days, the assumption is “This is how long it would take if I had nothing else to work on.”

Ideal days are usually used in conjunction with some sort of “efficiency coefficient” whereby someone takes the ideal days and multiplies them by the number of actual ideal days you can get in a week.  For example, in 5 business days I get 3 ideal days of work done, so the coefficient is 3/5.  Therefore, if I estimate this work in ideal days and call it a 3, it will take me a week.

I’m not a big fan of using ideal days as an estimation method for a few reasons:Anytime you use calendar time for estimating, no matter the caveat, it tends to be used as a commitment.  Estimates != commitments, especially in complex-creative work.It creates a distracting vanity metric:  Getting ideal days to match calendar days (disguised as a quest for “efficiency”).  With this, instead of focusing on delivering value, the teams focus on “making the numbers match”

Story Points/Tshirt sizes

Story points are a way to decouple the estimation of size and effort from the duration of time.  Instead of trying to estimate how long something will take, you estimate how big it is and let your velocity data tell you how long it will take.

If you don’t have velocity data, take your best guess in terms of how much work a team can do in a sprint, then measure the actual when you have actual data.

I like story points as a sizing practice because once the teams get their minds around decoupling time and effort, it makes it easy to estimate large amounts of work quickly.

Be careful:  Its not a good practice to try to map story points to days directly.  The point of decoupling is to understand the change in the relationship between time and points, which changes as teams improve, add new members, get reconfigured, etc.

Threshold-based sizing

Another form of sizing I like to use is “Threshold-based sizing.”  This is where we set a threshold (say 3 days) and when we estimate, we are only interested in getting stories under the threshold.  This eliminates distractions around precision (2.3 days vs 2.8 days) and moves the stories toward a standard size.

For stories that are above the threshold, we split them, or decrease the scope, or cut functionality until they are below the threshold.

My preference is to use a combination of tshirt sizes and threshold estimation

At the release level, I like to use chunky tshirt sizes:  XL, XXL, XXXL

At the sprint level, I like to see smaller, more granular tshirt sizes:  S, M, L

When we go into sprint planning, I take the stories slated for that sprint and apply the threshold method, as a double check.  When applying the threshold, I use the rule of 1, 2, 3:

  • 1 user story should take
  • 2 people no more than
  • 3 days

Maybe its a developer and a tester, maybe its a front end developer and a back end developer, or maybe its 2 full stack developers.  The composition of the 2 people working on the deliverable doesn’t really matter to me.  What matters to me is that we are spreading knowledge around the team so we don’t end up in a situation where “Only on person knows about this..”

What are some other ways of estimation you have seen?

 

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

Read More

How to Decompose User Stories into Tasks

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

Recently I was looking at the sprint backlog of a team, which just started their agile journey. When I looked at the task break down of the user stories, I noticed something like this.
User Story:
Coding
Testing
Check-in
Build
Demo

 

Looking at this task breakdown, it felt like a sequential process steps defined as tasks for a story. I also noticed that every story had the same task break down with different effort estimates. I was looking at their done criteria of a story. I could not really relate their Definition of Done (DoD) and their task break down. Immediately, I asked one of the team members, “How do you make sure that you complete every task listed in the DoD? “  He stared at me with a confused smile, and said “We just do it! Sometimes there were tasks, we forget few of them and will get them done in the next sprint!”

Ah! Here is the catch…

I see that the task break down of the team just reflects a sequential process and doesn’t convey anything meaningful about what is happening with that story! Moreover, the task “Coding” doesn’t convey how much portion of coding completed for a specific story.

I also found a similar pattern of task splitting with other team’s sprint backlog too!

Somehow, I find that many teams are struggling to do an effective task down of a user story!

A task is a piece of activity that is required to get a story done

Here are some effective tips for breaking down a user story into tasks.

1.  Create Meaningful tasks

Describe the tasks in such a way that they convey the actual intent. For example, instead of saying Coding, describe the tasks as  “Develop the login class”, “Develop the scripting part for login functionality”, “Develop the password encryption for the login functionality”, “Create user table and save the login data to DB” etc.. Such tasks are more meaningful rather than just saying coding and testing.

2.  Use the Definition of Done as a checklist

Let us see what a DOD is very quickly.  The DOD defines the completeness criteria of a story. It includes all items that have to be completed to claim that the story is done by the development team. A simple example:

  • Acceptance criteria is verified during testing
  • Coding tasks completed.
  • Exploratory Testing completed and signed.
  • Regression test reviewed and passed.
  • Unit testing – written and passed.
  • Code reviews conducted.
  • Defects are in an “acceptable” state to the Product Owner.
  • User story accepted by the product owner.
  • Regression tests run and passed
  • Smoke / automation tests run (if applicable)
  • Check for memory leaks
  • Automated unit tests are checked in
 Now how do you ensure that all items of DOD are done by the team? One way is to use the DOD as a checklist to come up with tasks for the user story so that the team can take each one of them and complete without forgetting.

3.  Create tasks that are right sized

Another syndrome I have seen is tasks which are very small, broken down to a minute level like, 10 min, 30 min, 5 min tasks, for example: Write Accept User Name Password, Validate Login, and Give Error Messages. Breaking the user stories with too many details is an overhead. What is the ideal size of the tasks?

One guideline is to have tasks that span less than 8 hours so that each one of them can be completed in at least a day.

4.  Avoid explicitly outlining a unit testing task

If possible, make unit testing not a separate task but part of the implementation task itself.  This encourages people to practice Test Driven Development as an approach. However, this practice may not be ideally suitable for new Scrum teams.

5.  Keep your tasks small

Do not have tasks that span across days together.  Its makes it difficult to know the actual progress.

In some mature teams, I have seen, they do not do the task break down at all. They just pull in the user stories and complete them, but it is a journey for new Scrum teams to get there, and requires a strong cohesive team, and many sprints of working together.

So, how often do you think, as a team, you have to revisit the DoD, so that your task breakdown may change?

 

 

 

 

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

Read More

How to Develop User Stories

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

I sat in Doug’s office.  He was panting.  He was sweating.  As the Director of Product Management, part of his job was to ensure his product managers knew what they were doing.  The transition to Agile was giving him a headache, because now all his product managers had to learn to become product owners.  This meant learning how to write stories, but this was not the only problem.

The much bigger problem was that there was a major initiative put forth to turn the company around, and everybody, including the CEO, was dependent on this initiative to be a success.  The project had already started, and the product owners were scrambling to figure out how to develop user stories.  They tried sitting in a room with the business analysts creating requirements, but they weren’t very good nor very actionable.

In this article, I will lay out 4 techniques on how to develop user stories.

shutterstock_127187282

Technique 1:  User Interviews

Most users have no idea what they need.  If you press users, you will get answers, but most likely they will give only a superficial insight into what’s needed.  Users are very good at identifying their problem, but not very good at identifying a solution.

Conduct 1 on 1 and small group interviews to talk about users’ pains.  Pay close attention to the problems, but take proposed solutions with a grain of salt.  Use judgement and understanding to take those problems and turn them into user stories.

shutterstock_139696711

Technique 2:  Questionnaires

Questionnaires are good if you have a sizable user population.  I have had great success in using questionnaires to gather information for large ERP and PLM implementations.  However, be careful in using questionnaires as the primary means of communicating with users to gather their problems.  Compared to a 1 on 1 interview, there is little opportunity to follow clues and context.  Your only tool is the response in the questionnaire.

Make sure your questionnaires are well written, with specific questions that can help you further identify trends among your user base.

shutterstock_134416205

Technique 3:  Observation

Direct observation is great, and when paired with user interviews, create a 1-2 punch that helps you develop your user stories in a more direct manner.  This is easiest when you are developing in-house solutions, as on site observation for far flung customers could be cost prohibitive.

Go to where the user typically works, and observe their habits.  Pay attention to the steps they take in the system, and compare that to what they are actually looking to accomplish on a day to day basis.  Observe how comfortable they are with technology in general, and look for ways you can make them more successful in their day to day work.

shutterstock_158984081

Technique 4:  Workshops

A workshop to develop user stories is a meeting that has the complete team plus end-user stakeholders.  During this meeting, users write down as many stories as they can think up.  Conducting workshops is a very effective way to gather a large number of stories quickly.

After there is a large number of stories, you will want to map them out into user flows.  As you walk through the user flows, ask questions like:

  • What will the user want to do next?
  • What mistakes could the user make here?
  • What could confuse the user at this point?
  • What additional information could the user need?

shutterstock_130392182

Agile processes help you integrate new and emerging requirements throughout the process

At the beginning of your release, you should still take some time to conduct some sort of exercise to develop your initial set of stories.  Rather than relying on one way to develop your user stories, you should use a combination of all the ones listed here, plus any others you may come up with.

What are some other way to develop user stories?

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

Read More

How to Write a User Story

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

For those of us who have been practicing agile professionals for some time, we sometimes forget that not everyone is familiar with the terms and jargon associated with agile and scrum. User stories, unfortunately, fall into the same trap. Everyone talks about them, but not everyone knows what they are. In this article I will show you how to write a user story.

I sat in my makeshift cube in a far corner of the second floor…where they put the consultants.
A business analyst comes rushing into my area, “I have to write user stories!”
I stared blankly… “and?”
“And I have no idea how to write one or even what it is!!”

Step 1: Describe who wants the feature

The purpose of a user story is to help everyone understand WHO wants WHAT and WHY.  When we talk about the WHO, its not just in terms of who the user is, but also things like

  • What do they do day to day?
  • What is their level of comfort with technology?
  • What goals are they trying to accomplish?
  • What are the daily pains they deal with?

Before you dive into user stories, make sure you understand who your users are and can answer the questions above for each user.  Being able to describe your users in this way gives context to the user story and a foundation for the conversation.

Example User:  Online Holiday Shopper, rarely shops online except during holiday season.  Average comfort with computers and the internet, but throws hands up at technical jargon and javascript error messages.  They want to shop online and avoid the lines and traffic of the brick and mortar experience.  Top ecommerce pains:  Having to double ship, slow shipping, opaque order processing, having to call customer service to find out the status of an order.

Step 2: Describe what they want

The primary difference between user stories and other types of requirements is that user stories describe functionality in terms of outcome, while other requirements describe functionality in terms of system activity.  This is part of what makes the user story so powerful.

Describe the desired outcome of the user in the user story.

Example Outcome:  Online Holiday Shopper wants to be able to ship gifts to an address that is not their credit card billing address.

Step 3: Describe why they want it

Another big difference between traditional requirements and user stories is context, aka the WHY.  Context is important because

  • It helps us understand the value associated with the functionality
  • It gives us the opportunity to explore other ways of reaching that goal

Example Why:  Online Holiday Shopper wants to be able to ship gifts to an address that is not their credit card billing address so they don’t have to double ship their purchase

Step 4: Create acceptance criteria around the new feature

A user story is not complete without acceptance criteria.  Acceptance criteria represent a way for us to validate the intent of the functionality by having test criteria defined up front.

Example Acceptance Criteria:  Online Holiday Shopper wants to be able to ship gifts to an address that is not their credit card billing address so they don’t have to double ship their purchase.

  • User can add up to 10 addresses in their ‘address books’
  • International addresses not supported
  • User can add addresses in their ‘account settings’ or during checkout
  • Shipping rates need to be recalculated based on shipping address chosen

Step 5: Engage in conversation to fill in the details

Remember, a user story is the promise of a future conversation, and are not meant to be a substitute for team members talking to each other.  After you have the conversation, fill in additional agreed upon and discussed details.

There are a few key takeaways:

  • The user story does not stand alone.
  • The conversation is the most important part of the user story.
  • User stories are progressively elaborated.

What are some other challenges you have in understanding and creating user stories?

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

Read More

How User Stories are Different from Requirements

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

I was packing up my things, ready to leave after a long week of training.  Susan, the lead business analyst, had been dutifully attentive all week.  She took excellent notes, asked probing questions, and seemed to be integrating the new knowledge smoothly.

“Hey Tirrell, I have a question for you…”

“Shoot”

“So exactly how are user stories different from requirements?”

When people say “requirements”, especially in my neck of the woods, they are referring to IEEE Standard 830 “The system shall” style of writing requirements.  Here are some examples:

  • 1.2)  The system shall allow a user to buy a cake with a credit card
  • 1.2.1)  The system shall accept Visa, Mastercard, and American Express
  • 1.2.2)  The system shall charge the credit card before the cake is made
  • 1.2.3)  The system shall give the user an order number

You get the idea.  One problem with documenting requirements this way is that its very very tedious and time consuming.  Another problem is that its boring to do, and even more boring to read, which is why long detailed requirements documentation rarely gets read.  Lastly, because requirements are written at such a granular level, its difficult to understand the big picture.

User Stories are Goal Oriented

Traditional requirements are created from the perspective of the system and its associated activities.  Problems with interpretation of these activities lead to pain and missed deadlines because they tend to be interpreted as edicts rather than points of discovery.  In other words, they tend to over specify.  This leads us to a situation where highly paid intelligent engineers don’t get the opportunity to solve user’s problems, they are stuck implementing a sub optimal solution.

Unlike traditional requirements, user stories tell is what the user is attempting to achieve.  This is important because it gives context to how we view the requirements.  Since there are multiple ways to help a user accomplish the goal, it ensures the solution meets the goal (or the problem the user is trying to solve).

User Stories Allow for Quick Level of Effort Estimates

In waterfall, there is a traditional requirements gathering phase that may be 20-30% of the overall project timeline.  Therefore, the team doing the work can’t give estimates until after the specifications have been written.  This leads to friction because the teams are often railroaded into a timeline that doesn’t match with the requirements, but the timeline and budget were decided before the specs were written.  Catch 22.

With User Stories, a team can look at what the user is attempting to achieve, and give an associated estimate usually within minutes or hours rather than the weeks or months associated with traditional requirements.

User Stories Allow for Negotiable Scope

Traditional requirements tend to be “all or nothing” and have no sense of prioritization.  Therefore, the scope of traditional requirements is not negotiable.  This can lead to what is known as “value engineering”, which is the practice of creating quick, but fragile solutions as to get all the functionality completed on time.

With user stories, if the level of effort estimate is different from what the project sponsors thought, the team and product owner can take a look at the goals of the users in the stories, and think of other, less feature rich (but still usable) ways to help the user achieve their goals.

IEEE Standard 830 was last updated in 1998

A lot has happened in software development since then, but many companies have not yet revisited how they create requirements, so I still see a lot of this in the field.  Often, its because a decision was made 15 or so years ago to write the requirements this way, and armies of business analysts were hired to support this decision.  In short, continued use of IEEE 830 style specs is just as much a function of inertia as it is conscious decision making.

How do you write specs at your company?

 

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

Read More

How to Write Good User Stories

 

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

A question that comes up a lot is how to write good user stories.  I can only assume because people have seen many examples of bad user stories out there.
“We can’t use ‘user stories’ for our type of work.  Its too complex and the user stories don’t contain enough detail”
“Why can’t you use user stories?”
“Because we cant build a system from 50 one-liners!”

Uh-oh.  Maybe you have seen this situation before, maybe you have been in this situation before either as an engineer or as a product owner.  Either way, its a tough spot to be in.  Here are some times on how to write good user stories.

Tip 1.  There is no story without a goal.  Start by outlining the goals of the users in the system.

Remember, user stories describe functionality in terms of the outcome, or the goal of the user.  Once you understand what the user is trying to achieve, it makes it much easier to create a good user story.

Tip 2.  Include metadata or other artifacts with the user story.

There is a misguided conception that a user story can ONLY include the user story, and not additional artifacts as needed.

Realistically, you are still able to use anything and everything valuable at your disposal to help with the communication process.  User stories are the beginning of the conversation, but not ALL communication.

Tip 3.  Make sure you have a set of cards with the different user personas described.  If you don’t have them, make some.

One of the reasons user stories do a poor job of communicating is because all users are treated the same.  How many times have you seen “as a user…” on a user story?  However, there is no system of a non-trivial size that does not have multiple types of users.  Understanding who those users are, what their pain points are, and how we can address those pain points goes a long way toward being able to write good user stories for those users.

Tip 4.  Involve the customer in writing the stories.

When we sit down to figure out what needs to be done for the user (aka the customer), we often shy away from involving the customer in those conversations.  This is because we think we should know everything.  While we should be aware of the customers needs and goals, the best way to get that information directly is to talk directly to the customers about their wants and needs.  Even better, if you can involve the customer in writing the user stories (at least the high level description), you stand a much better chance in delighting the customer with the product.

Tip 5.  Keep the stories short, remember, they’re just reminders to have the conversation.

User stories have 3 parts, the card, the conversation, and the confirmation.  The conversation is the most important part.  This could mean conversations with stakeholders and customers to outline what they want, AND it includes conversations with the team to articulate the business need.  There is no substitute for talking, and one of the positive aspects of Scrum is that it shifts the focus from documenting customer needs to actually talking about them.  As a product owner, part of your “secret sauce” is to be able to communicate a vision, in both the big sense and the small sense.

Keep an open mind

Some of the challenges teams have with writing and consuming user stories can be avoided by not having a rigid idea of what a user story is.  The user story is just a starting point for the all-important conversation.  Then you can flesh out and add details to reflect the shared understanding.  What kind of problems do you have with writing good user stories?

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

Read More

How to Create a User Story Map

 

 

 

 

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

She stopped me in the hallway, lips tight, brow furrowed, hands a maelstrom of gesticulating madness.  She didn’t have to open her mouth for me to begin the conversation, “Hey Anita, how are you?” “Not good, I have all these user stories the business analysts created, but we have no idea how to organize them” “Ok, lets take a step back and make a story map, that will help us figure out where the gaps are.”  In this article, I will talk about how to write a story map.

A User Story Map is a representation of a set of user stories along 2 dimensions:

At the top of the hierarchy is the Epic.

An Epic is a large activity that has user value, such as “Buy a Plane Ticket.”  Some prefer to use the user story format to create epics, but to me it really does not matter.  We just want to use a phrase or sentence that captures the spirit of what we want to accomplish.

Next, you have the workflow itself, which is divided into themes.

A theme is a collection of related stories, and the themes roughly correspond to workflow steps necessary to fulfill the value outlines in the Epic.  Here is an example, using plane ticket purchases:

Buy a Plane Ticket

  • Flight search
  • Shopping cart options
  • Checkout/payment options
  • Fulfillment options
  • Post-sale options

“Buy a Plane Ticket” is the epic, and the epic is broken down into a number of themes, such as “flight search” and “shopping cart options.”

StoryMap

Each theme is then broken down into a set of stories that are arranged in priority order.  The items near the top of the priority are more likely to be implemented first.  The others are more likely to be implemented later.  The top layer of the stories represent the minimal marketable features.

A story map is not a release plan.  It helps us see the breadth and depth of stories to be implemented and merely influences the release plan.

A good story map:

  • Shows us the flow of activities from the users’ perspective
  • Informs architecture/infrastructure needs
  • Outlines user stories’relationship to each other
[activecampaign]

Step 1:  Outline the major goals (epics).

These  are your highest level of user value.  To come up with these major goals, think like a non-technical user.  Users tend to describe applications in broad non-technical easy to understand terms that represent value.

  • Facebook lets me stay in touch with family
  • Mint helps me with budgeting
  • Evernote allows me to take notes anywhere

These epics are the same language you would use to describe the functionality to your mother or a friend who doesn’t work in the technology industry.

Step 2:  For each epic, outline the user flow from beginning to end.

Start by outlining the steps.  Sometimes this is difficult.  After you create a step, ask yourself, “Then what happens?”  This will get you to the next step.  Do the flow first before diving into the stories.

Step 3:  For each theme, outline and prioritize the user stories associated with that theme.

After you have outlined the steps, start thinking about the different ways to accomplish that step.  Those will be your stories.  For each story, consider “what happens if… ” scenarios, that will deepen the user story list.  There will be some stories that are obvious high priority, and others that will not.  Often during story mapping new stories appear from looking at the problem from a different angle (horizontal and vertical).

Treat the map as a living artifact

Congratulations, you now have a story map!  Story maps are very useful to create at the beginning of a project, and helpful for release planning.  Like all Agile artifacts, story maps are living artifacts.  Make sure you revisit the story map every few sprints to add/update stories, and to reflect new stories and new lessons from project execution.

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

Read More