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:


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

Announcing: The Ultimate Guide to Building Your Backlog


I took 8 years of backlog building experience and stuffed it into a new and exciting book and course.

This was created because I saw so many product owners struggle with building backlogs.  When I would work with new teams, they would be excited for the possibility of what Agile could bring, but that excitement soon would turn to horror as the team was forced to try to consume backlogs in horrible condition.

Imagine buying a brand new house only to find the foundation was cracked, the beams were rotten, there were mice living in the walls, and termites were eating the roof.

This is what a poorly created backlog feels like to a new team.  A team that is forced to work like this will be demoralized and demotivated.  It certainly does not set the stage for a productive, excited, engaged team.

This material will show to take all the thoughts and information in your head and create a crisp, clean, prioritized backlog for your team.  You will be able to smoothly negotiate the rough spots with your team and stakeholders?

It’s not just about “building your backlog” — it’s about making your stakeholders and teams happier, which in turn makes you more respected by them and gives you the reputation as the go-to person when the stakes are high and the project is important.

My comprehensive workbook is guaranteed to help you totally transform how you build backlogs, or I’ll refund you in full.

Click here to get it

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

Read More

Why you should give your teams problems to solve, not solutions to implement

In my role as a consultant, part of what I do is observe problems. Here are some of the problems I observe:
– Technology leaders stressed out, banging their heads to find solutions to difficult business problems.
– Technology teams not fully engaged, waiting for the next “unrealistic thing to implement in an unreasonable timeline” from leadership. – Customers who don’t feel like their success is at the core of how their service providers do business.

In this article I will explore the practice of giving problems to the team to solve, rather than solutions to implement and how it improves leadership’s leverage, teams’ engagement, and customer satisfaction.

The secret of leverage

Here is the dirty little secret of business, “Leverage is the difference between effective leadership and ineffective leadership.” What I mean by leverage, specifically, is the art of using resources around you to multiply the impact of your strategies and execution.

How this applies is that most technology leaders became leaders because they were good at technology. In fact, most of them were so good they were promoted. So they are used to being the person with the answers, able to create elegant solutions to difficult problems.

Its not your job to be the smartest guy in the room

However, when you move to a position of leadership, its no longer your job to be the smartest guy in the room. Its your job to create teams of people who are smarter than you. Why? So you can leverage their intelligence. 10 smart people looking at a problem will envision a wider range of acceptable solutions.

Pro tip: Don’t keep the problem space to yourself in your head. Explain to your teams the top 3 business problems you and the rest of the leadership are trying to solve.

Engaged employees don’t need to be told to work hard

Have you ever had those moments where you just fall into the flow? Where the direct line from your creativity and your logic just meld together into an ever-satisfying melange of bright shiny goodness? I’m sure you have. This is what being fully engaged feels like. Unfortunately, most of your teams are not fully engaged.

They aren’t fully engaged because no one is engaging them to actually help solve problems. I talk to countless numbers of front line workers and middle management and a lot of them have the same complaint, “Leadership goes off and comes up with some hair-brained solution on an unrealistic timeline and we’re supposed to make it happen.” This is a source of frustration and even worse, a source of disengagement.

Pro tip: Involve some of the members of your teams into your high-level planning sessions, ask their opinions, and really consider their input. People are more likely to buy into a solution they helped co-create.

Your customers are why you’re in business

The very core of what you do is to solve problems your customers are willing to pay to have solved, but your customers problems may not permeate beyond the “business development” layer of your organization.

Its important to keep the “customer mission” at the top of mind when engaging your problem solvers. Helping everyone understand the customers’ problems means that we reduce the risk of “a solution looking for a problem.”

Pro tip: Make sure the understanding of customers problems’ extend beyond sales and marketing into the technical teams mindsets.

Better customer engagement, better employee engagement, better solutions overall.

Whats not to like? You’re in business to serve your customers, and technical teams are technical because they like to solve problems. Lucky for you, that fits right in line with the core mission of your business. Give your teams problems to solve rather than solutions to implement, you will be amazed at the results

Until Next Time, Stay Agile, My Friends

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.


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.


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.


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.


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?


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…”


“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