Articles and Posts Tagged “product-backlog”

Now vs. Not-Now Prioritization Along with Medium-Term Goals

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves,...

Simplify Prioritization into “Now” and “Not Now”

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason,...

Choose Backlog Items That Serve Two Purposes

I've been playing a fair amount of Go lately. If you're not familiar with Go, it's a strategy game that originated in China 2,500 years ago. It's along the lines of chess, but it's about making territory with black and white pieces played on the intersections of a grid of 19x19 lines.

Like Scrum, there are very few rules in Go. Also like Scrum, there are a fair number of principles,...

Adding Decorated User Roles to Your User Stories

When writing user stories there are, of course, two parts: user and story. The user is embedded right at the front of stories when using the most common form of writing user stories:

As a <user role> I <want/can/am required to> <some goal> so that <some reason>.

Many of the user roles in a system can be considered first class users. These are the roles that...

4 Tips for Spring Cleaning Your Product Backlog

he following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

It's May, and we're well into spring now. If you're like me, you haven't yet done your annual spring cleaning. But I'll do mine this week, if you promise to also do yours.

The type of spring cleaning I'm referring to...

Paying the Cost for More Precise Estimates

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with...

2 Times to Play Planning Poker and 1 Time Not To

This post continues my recent series about Planning Poker by focusing on when to estimate.

Because Planning Poker is a consensus-based estimating approach, it is most appropriate to use it on items that require consensus. That is, I recommend using Planning Poker on product backlog...

Building a Product Users Want: From Idea to Backlog with the Vision Board

Vision and Backlog

Scrum is a great framework for building a product with the right features. It encourages the use of a vision shared by the product owner, the ScrumMaster, the development team, and the stakeholders, and it provides a product backlog that allows the team to move towards the vision by creating

3 Roles That Need to be Involved in Agile Estimating with Planning Poker

When estimating your product backlog with Planning Poker, it’s important to have the right people participate. Let’s go over who needs to be there, and what the job of each is during an agile estimating meeting. First, of course, we start with the team. All of a Scrum team’s...

Know Exactly What Velocity Means to Your Scrum Team

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

To see how this applies to an agile project, consider the issue of whether a team should earn velocity credit for fixing bugs during a sprint. A team that uses velocity to measure how much functionality is delivered in a sprint will not claim credit for bug fixes. No new functionality...

New Year’s Resolutions for ScrumMasters and Product Owners

With the new year, it's time for some resolutions. I've got the same old ones (lose weight, eat better, get more sleep, help more old ladies across the street, stop calling every cat I see "Fajita," and such). But since I fail at those every year, I thought perhaps it would be better for all of us if we made some Scrum-related resolutions. And so here are a couple of…

How to Be Sure You’ve Thought of Everything

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted here.

A common question I get is how can a product owner (or team) be sure they've thought of everything when writing a product backlog. The question is especially common from teams doing…

Product Backlog Bankruptcy!

The following is a guest post by Ilan Goldstein, author of "Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips" which is full of advice on speeding up your adoption of Scrum. It's a great book I can highly recommend. You can read my foreword to it for more of my thoughts. Here are Ilan's thoughts on what to do with a large product backlog.
--Mike

You’re…

When You Miss the Point of Sprint Planning Meetings

In a recent interview for an upcoming agile book by Sondra Ashmore and Kristin Runyan, they asked me questions regarding several areas of agile development and Scrum. In the last two posts, I explored questions about the product backlog and estimating. This time, I’d like...

How Can We Get the Best Estimates of Story Size?

I was recently interviewed for an upcoming agile textbook written by Sondra Ashmore and Kristin Runyan. They asked me questions regarding several areas of agile development and Scrum. Last week, I explored questions they had about the product backlog. This week, I'd like to tell you about the conversation we had about estimating.

The conversation began as follows:...

Backlog Grooming: Who Should Attend and How to Maximize Value

I was recently interviewed for an upcoming agile textbook written by Sondra Ashmore and Kristin Runyan, and they asked me some questions about backlog grooming, such as who should attend, how to maximize the value and if the meetings can ever be fun. I’d like to share with you my thoughts on those questions today.

Names Should Not Be Needed for User Stories

I've never been a fan of naming user stories. Stories should generally be short enough that naming them should be necessary.

Yes, novels and movies get names. But we don't name the sentences in a novel. Since I still haven't been to see The Great Gatsby movie I started re-reading the novel recently so it's on my mind. Imagine Fitzgerald and his editor (Maxwell Perkins) discussing the book and Fitzgerald saying...

Three Tips for New ScrumMasters

One of the most common questions I get is "Now that I've taken a CSM class, what should I look out for when I return to the office?" While every situation is different, most new ScrumMasters should be aware of the following three issues.

First, remember the values and principles, the why-we-do-what-we-do portion of agile. Without a good set of principles and values, people…

Learn Agile Estimating Online with Mike Cohn for Half Price

We’ve decided to run a spring sale of our popular eLearning course: Agile Estimating and Planning. Until May 19, you can access the entire course , worth 4PDUs, for half off. Some of the things we cover include:

  • The problem and the goal.
  • Story points and ideal days.
  • Estimating the product backlog.
  • Release planning.
  • Multi-team projects.

Here’s a sneak…

Using Scrum on an Analysis Project

Last week I wrote about "Sprint Zero" and made the point that on the rare occasion when this might be a good idea, Scrum teams would be better off thinking of that time as a "project before the project." Projects do not spring to life fully formed--that is, staffed and ready to be worked on. The vast majority of projects can, though, be instantly started and things like…

Sprint Zero: A Good Idea or Not?

In my previous post, I wrote about alternatives to numbering sprints. In this post I want to deal with a very special number that some teams use in numbering their sprints--zero.

The concept of a "sprint zero" has become popular with some teams and so it is important to consider whether or not this is a good idea.

First, let's agree on the basic premise of "sprint…

Two Examples of Splitting Epics

A Scrum trainer recently asked for a couple of good, real examples of large user stories (epics) being split into smaller stories. I thought it would be useful to share those examples here as well since the companies where these came from gave me permission to share them.

Example 1: Selecting Marketing Campaigns

This first example is from a company that sells software to…

Handling Requirements from Architects Outside the Team

I was recently asked what I thought about using the "Wise Architects" in a company to provide technical oversight to the multiple teams on a project.

A common objection to this is that the architects are outside the team and should not, therefore, have any say in how the team builds whatever it is that they are building.

This argument doesn't hold water, though, as there…

The Rules vs. The Generally Accepted Practices of Scrum

In a post back in March I introduced a term on this blog that I'd been trying out in discussions and a few classes. The term was GASP and it stood for a Generally Accepted Scrum Practice. What I'm interested in right now, and I'm hoping everyone here will help with, is creating a list of all the GASPs we can think of.

But first, we need to more formally define what a GASP…

GASPing About the Product Backlog

I've been wondering lately if Scrum is on the verge of getting a new standard meeting--the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the start of the next sprint.

To see why a Backlog Grooming Meeting may be a few years away from becoming a Generally Accepted Scrum Practice, or what I call a GASP, let's revisit the early 2000s.

Points Are About Relative Effort Not Ranking

I'm thinking of buying a new car. So I've put together a list of cars to consider. Here they are in priority order:

  • Bugatti Veyron Super Sports
  • Pagani Zonda Clinque Roadster
  • Lamborghini Reventon
  • McLaren F1
  • Koenigsegg CCX
  • Porsche Carrera GT
  • Aston Martin Vanquish
  • Toyota Prius
  • Toyota Camry
  • Tata Nano

Unfortunately, though, I'm not…

In Defense of Large Numbers

People are often surprised that I allow (or even encourage) people to estimate with story points as large as 20, 40, and 100. We include these values in the decks of Planning Poker cards that we sell and give away in classes and at conferences. Yet many people tell me they start out my taking the 20, 40 and 100 cards out of the deck and throwing them away. I find this…

Estimating a Full Backlog Based on a Sample of It

I want to address a question I was sent recently and that I get asked about once a month. The question has to do with how we estimate how many hours it will take to deliver a given product backlog if we have no historical data at all. My first bit of advice is always to try to put off answering until you're able to get even one sprint of historical data. But that's not…

A Sample Format for a Spreadsheet-Based Product Backlog

I want to show a real easy way to put user stories in a spreadsheet-based product backlog. I wrote this after seeing someone tweet a screen capture of a product backlog I made nine years ago and thought to myself, "Yikes, that's out of date for how I do it today ..." So in this post, well look at an agile product backlog template in Excel. 

As you probably know, I'm a big…

Estimating Non-Functional Requirements

A few weeks back I promised someone I would blog about the unique challenges of estimating non-functional requirements. First, let's remember that a non-functional requirement is a requirement that is more about the state of being of the system than about one specific thing the system does. Non-functional requirements often have to do with performance, correctness,…

A New Artifact - The Long-Term Product Backlog

The weather turned nice about two weeks ago, which meant it was time for spring cleaning about the Cohn home, affectionately known as the Cohnderosa (which will only mean something if you're old enough to remember "Bonanza"). While washing the windows around the outside of the house I had plenty of time to think about spring cleaning I'd also just helped a couple of clients…

Deciding What Kind of Projects are Most Suited for Agile

I was recently asked what kind of project is most suited for the agile process. In my view, the most appropriate projects for agile are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them. We want to use agile when we are doing something that is new, or at least new to the team building it. If it's something the team…

Estimating Work Shared Between Two Backlog Items

Product backlog items can be ideally written to be independent. It is the hallmark of a good team that its members can implement product backlog items in any order. However, it would be nearly impossible to remove all dependencies between product backlog items and so our goal becomes minimizing important dependencies rather than eliminating them altogether. But any…

It’s Effort, Not Complexity

A client asked me, "When will my team be done with this project?" This is probably the bazillionth time I've been asked that agile project management question in one way or another. I have never once been asked, "How hard will my team have to think to develop this project?" Clients, bosses, customers and stakeholders care about how long a project will take. They don't care…

New Tools for Prioritizing Backlogs Available

We've added two new agile project management tools for prioritizing a product backlog: Theme Scoring and Theme Screening. Each of these is a lightweight way of comparing product backlog items to one another.

Theme Scoring

You can use theme scoring to compare user stories or entire projects against one another. In this technique you identify a set of criteria that will…

Announcing the Tools Section of Our Website

A nice side effect of having the Succeeding with Agile book done and in print is that some of my time has freed up for other projects. One such project has been the creation of some free agile project management tools that we're making available on the Mountain Goat Software website. I've wanted to make some of these available for a long time so it's nice to finally be able…

Distributed Teams: Build Trust through Early Progress

Critical to creating a coherent team is building trust among team members. This is much more difficult on a distributed team. Unable to rely on repeated, frequent face-to-face communication, distributed teams need to take other measures to build trust. Traveling ambassadors, starting meetings with casual conversations, occasional in-person meetings of the full team, working…

Remove Finish-to-Start Activities on Agile Projects

When it comes to agile projects, one element of agile project management that is difficult for teams to master is how to overlap their work. If a team doesn’t learn effective ways to do this, team members may settle on a less desirable approach: activity-specific sprints. An activity-specific sprint is as bad a practice as it would be an acronym. In this approach, the team…

Mix the Sizes of the Product Backlog Items You Commit To

Teams used to a sequential development process have become accustomed to hand-offs between specialists. Analysts hand their work to designers who hand it to programmers who pass it on to testers. Each of these hand-offs includes some overhead in the form of meetings, documents to read and perhaps sign, and so on.

In part because of this overhead, the hand-offs tend to be…

Make the Product Backlog DEEP

Roman Pichler, author of "Agile Product Management with Scrum: Creating Products That Customers Love" and I use the acronym DEEP to summarize key attributes of a good product backlog:

  • Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that…

Agile Design: Intentional Yet Emergent

The agile process favors an incremental, just-in-time approach to design. As such, Scrum projects do not have an upfront analysis or design phase; all work occurs within the repeated cycle of sprints. This does not mean, however, that design on a Scrum project is not intentional. An intentional design process is one in which the design is guided through deliberate, conscious…

How Do You Get from Here to Agile? Iterate.

Historically, when an organization needed to change, it undertook a “change program.” The change was designed, had an identifiable beginning and ending, and was imposed from above. This worked well in an era when change was necessary only once every few years. But in today’s fast-paced, ever changing environment, it makes more sense to create agile organizations, ready to…

Mike Cohn speaking at Agile Development Practices in Orlando, Florida

Learn the latest in agile methods, technologies, tools, and leadership principles from thought leaders who deliver inspiring keynote presentations, in-depth tutorials, and a wide range of conference classes. Network with your peers during informal gatherings and discuss your challenges with experts in agile practices.

He will be presenting the following half-day tutorials:…

Bugs on the Product Backlog

A common agile project management question is whether bugs belong on the product backlog. Before I address that question, let me clarify that the question refers to bugs that are unrelated to functionality being coded during the sprint. If someone finds a bug during a sprint that is related to the features being worked on, the best thing to do is yell, "Hey, Mike, the boojum…

Using a Task Board with One Remote Team Member

I want to address a question I was emailed yesterday but that I receive frequently. What should we do in the case when the team really likes having a task board, but when one team member is remote? My first answer is always: Try to get the one person to move to where the rest of the team is.

I don't expect to see any moving trucks roll out when I ask this, but I have to…

The Ideal Agile Workspace

As you may now, I am working on a new book, which will be called Succeeding with Agile. I recently finished writing a chapter for it on the impact of the human resources and facilities groups on an organization that is transitioning to an Agile project management approach. While writing that chapter, I put together a list of all the things that I think should be visible…

Why There Should Not Be a “Release Backlog”

I haven't heard the term "release backlog" in many months, but it's come up in three conversations over the past week. So, I want to share my thoughts on whether a team using an Agile project management approach should have a backlog known as a release in addition to the conventional Product and Sprint (or Iteration) Backlogs.

First, let's clarify what people mean when…

Clarifying the Purpose of Iteration Planning

I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let's consider what the purpose of iteration planning is. In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably…

Should a Team Swarm on to One Backlog Item at a Time?

This week I want to address the question of whether a team should work on one product backlog item at a time or whether it's OK to work on multiple items. In general, a team should feel comfortable working on multiple product backlog items at the same time during an iteration.

A typical seven person team will plan between five and ten items into an iteration. They'll…

Should the Daily Standup Be Person-by-Person or Story-by-Story?

I want to address a question that I got recently and that comes up every month or two. I was recently emailed the following:

Most of our teams complete 10 or more user stories per sprint. When answering the 3 questions in the daily Scrum, it was clear what each person was working on, but it wasn't as clear how each story was doing or when a story was in trouble. For…

Establishing a Common Baseline for Story Points

A common criticism of story points is that the meaning of a story point will differ among teams. In this post I want to describe how can we establish a common definition of a story point across multiple teams within an organization.

The best way I've found to do this is to bring a broad group of individuals representing various teams together and have them estimate a dozen…

Visualizing a Large Product Backlog With a Treemap

In the early days we promoted agile project management only for small teams because that was where it originated. We had plenty of experience to say that agile worked well on seven- to 10-person teams. We were also quick to learn the techniques that allowed agile project management methodologies to scale up to around 20 to 40 people. These days, though, there are many truly…

How To Fail With Agile

Not everyone involved in an agile transition wants the change to be successful. This tongue-in-cheek article details twenty things you can do to sabotage an agile transition. Of course, the twenty things also serve as reminders of things to avoid or watch out for.

Improving On Traditional Release Burndown Charts

I want to use this month's blog posting to introduce a type of burndown (and burnup) chart that I find useful. I've been drawing this style of burndown chart for years and have coached many of my clients to do the same. Unfortunately, we've had to draw it either by hand or in tools like Visio and OmniGraffle because the agile tool vendors haven't (to my knowledge) hit on…

Working with “Storyless Tasks”

A question I get frequently is what to do with tasks that do not belong to a particular user story or product backlog item. Common examples I’m asked about include tasks like “update the build server to use the latest version of FitNesse.” Fixing bugs from prior iterations are another common example. I’ve sometimes heard of these tasks that don't belong to a particular…

Advantages of the “As a user, I want” user story template.

In my user stories book and in all my training and conference sessions on user stories I advocate writing user stories in the form of:

"As a <type of user>, I want <some goal> so that <some reason>." While I consider the so-that clause optional, I really like this template. At a conference, someone asked me why. Because I get that question fairly often, I want to give…

Prioritizing Tasks Within a Sprint

In the discussion that ensued from another post here, Brian Bailey asked a great set of questions. The questions were big enough that I've moved them here. I'm going to intersperse Brian's questions and comments with my responses. Brian started with:

If the product owner is onsite and part of the same company, what role should she have in prioritizing tasks within a…

When Should We Estimate the Product Backlog

I was recently emailed a question asking whether the sprint planning meeting should start with time allocated for putting story point estimates on any user stories that have not yet been estimated. No, I don't think this is a good idea. Keep in mind that we put estimates on product backlog items (which I recommend be user stories) so that:

  • the product backlog can be…

Writing the Product Backlog Just in Time and Just Enough

This article addresses the issue of how much detail should be included in product backlog items and when that detail should be added. In answering that question it provides guidance on how to incorporate activities such as user experience design and architecture into agile projects.

Should Companies Measure Productivity in Story Points / Ideal Days?

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point--when trying to decide between calling something “two points” or “three points” it is clear they will round up if they are being evaluated on productivity as measured by the number of story points (or ideal days) finished per…

Why I Don’t Use Story Points for Sprint Planning

As described in Agile Estimating and Planning, I'm a huge fan of using story points for estimating the product backlog. However, I also recommend estimating the sprint backlog in hours rather than in points. Why this seeming contradiction? I've previously blogged on the reasons why I recommend using different estimation units (points and hours) for the different backlogs.…

Don’t Average During Planning Poker

I like to use Planning Poker to estimate the user stories on an agile team's product backlog. In this approach individual estimators hold up cards showing their estimates. If estimators disagree they discuss why, ask questions of their product owner (who should be present), and repeat until they come to consensus.

Team members often ask me whether they really need to come…

To Re-estimate or not; that is the question

Should a team that is estimating in story points ever re-estimate? This is a question I'm commonly asked and would like to address here. Most people have a natural feeling that re-estimating is somehow wrong but they can't quite say why. I'll encourage those individuals to stick to their hunches, and hopefully I can provide of the reasoning that supports your natural…

Programmers and testers (and others) can work together on things smaller than user stories

A common misperception is that testers cannot do any work during an iteration until the programmers finish a user story or product backlog item. However, the unit of transfer between programmer and tester can be smaller than the user story.

Let’s see how this could work through an example: Suppose a tester and I are working on the story about auto-incrementing the next…

Differences Between Scrum and Extreme Programming

Scrum and Extreme Programming (XP) are definitely very aligned. In fact, if you walked in on a team doing one of these processes you might have hard time quickly deciding whether you had walked in on a Scrum team or an XP team. The differences are often quite subtle, but they are important. I think there are four main differences between Scrum and XP:

  1. Scrum teams…

The Critical Path on Agile Projects

On traditional, sequential process an important part of the project manager's job is identifying the project's critical path. The critical path is the sequence of activities that will take the longest to complete and that, therefore, determines the overall length of the project. For example, suppose that my wife and I want to see a movie this afternoon. Before we can go to…

Sprint and release planning should be in different units

A common source of confusion on agile teams occurs when the sprint ("iteration") backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units. In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out. In…

The Need for Agile Project Management

Ken Schwaber and I co-wrote this article to help counter the misperception that agile projects do not need project management. The article outlines some of the responsibilities of the agile project manager.