Hi! I’m Mike Cohn and I’ve been blogging here since 2005. That means there’s a lot of content here.

I’ve prepared this handy guide to help you find what you want on the most important topics I’ve written about. In addition to blog posts, you’ll find links to presentations, videos and more.

To get started, scroll down to find the topic you’re interested in then click on one of the personally selected items on that topic.

From there, you’ll be able to navigate to more items on the same topic.

You’re probably aware that story points are meant to reflect the total effort to implement a user story or any product backlog item. I’m often asked whether a team can determine the total number of story points for an item by summing the number of points needed to program it, the number of points to test it, and so on by skill.

I want to offer five reasons why I advise against that.

First, it is a good thing when team members develop an appreciation for and understanding of the work done by those with other skills. That is, we don’t need testers to become programmers or programmers to become analysts. But each skill should have an appreciation for and understanding of the work done by the others.

If the testers estimating “testing points” that will later be added to “programmer points,” it is much harder to encourage this multifunctional learning.

Second, when work is split too granularly, the aggregated estimates can introduce more error than simply estimating the full work. Suppose a team estimates by skillset and includes five skills (programming, testing, design, etc.). Each subteam estimates their work to be ½ point. But wanting to avoid fractions and wanting to be safe, each subteam rounds up to one full point. In aggregate that means 2-½ points of work is estimated as 5 points. That is likely overcautious.

Third, estimating jointly ensures that everyone is estimating with the same set of assumptions. When estimating separately, a subteam of testers will make different assumptions than the subteams of programmers or database engineers.

Fourth, for some teams it can actually be more work. Estimating by skillset can take more total person hours than estimating a single value for a product backlog item.

Fifth and last, it is harder to ensure a consistent meaning for a story point. For points to be a useful planning tool, there must be a shared understanding of them across all functional subteams. The more skillset-based subteams, the harder it becomes to ensure that consistency.

I hope these five reasons can help you convince your team to estimate together. But should every team do it that way? Aren’t there some teams who might benefit from summing the estimates of skillset-based subteams?

I’m going to save that answer for next week.

Although I can't respond to personal questions, I do like to write about the topics you’re interested in. If you have a topic you’d like me to address in a blog post or weekly tip, suggest it below. I consider all requests and address those that are of the most interest to most readers.

Thanks. —Mike

Thanks!

Check your email for our delivery.

Better User Stories

Aaron Corcoran's Testimonial

Read about the full course and book your place by clicking here.

During an iteration planning meeting, a team won’t be able to think of all tasks they’ll need to perform during the coming iteration. Some tasks just can’t be anticipated in advance. But others can be and teams often fall into a habit of overlooking certain types of work.

For example, one team might forget to consider changes to reports. Another team might forget that changes to one part of the system often require changes to another part. Or a team might tend to forget that when they change this last part of the system, the VP of that area likes to see the proposed new screens early in the iteration.

Whatever they may be, most teams have some types of systematic omissions--that is, types of work they fail identify on a regular basis.

If you think your team is suffering from this, here’s a simple thing you can do.

For three or so iterations, make note of all tasks identified during the iteration. If you’re using a software tool, this should be easy. If you’re using cards on a wall, clandestinely put a little dot on each card immediately after the planning meeting so you can later identify the task cards written during that meeting.

In the next planning meeting, bring a list of all the tasks that were added during the previous iterations. Tell the team what you’ve done and that these are tasks that no one identified during the planning meeting yet needed to be done during the iterations.

Ask them to look for patterns. Are there certain types of tasks the team missed?

If so, create a list and hang it on the wall or add it to the project home page. I like to structure it in the form of questions to be asked during iteration planning meetings. Questions will be things like:

  • Have we considered ___?
  • Will this product backlog item impact ____?

I’m not recommending you do this to identify 100% of all tasks during the iteration planning meeting. That’s too time consuming (and impossible).

But if you find your team is not doing a good job of thinking about the sprint ahead, this can be a helpful technique.

 

P.S. Did you just happen to stumble across this page? This was connected to a weekly tip related to agile and Scrum that Mike Cohn delivers to your inbox. If you haven't yet signed up, it's fast and simple, and you can do it here.

This is a test page.

This page will not be seen. Going to https://www.mountaingoatsoftware.com/exclusive will redirect to the homepage.

Thank you for contacting us. We will reply to your inquiry shortly.

If you’re a Scrum Master (or any member of a Scrum team) who is trying to change some behavior with your team, consider asking one of the team members to help you out by subtly signaling that you’re doing the thing you don’t want to do. Something as simple as a nose touch, like this signal from the movie "The Sting" will suffice.

P.S. Did you just happen to stumble across this page? This was connected to a weekly tip related to agile and Scrum that Mike Cohn delivers to your inbox. If you haven't yet signed up, it's fast and simple, and you can do it here.

<!-- This is not visible. This page is a container for homepage variations -->

This 2-day Scrum training introduces the fundamentals of Scrum and provides hands-on experience to prospective Certified Scrum Masters and teams.

7 courses scheduled in Austin, Silicon Valley, Orange County, Dallas, London, Colorado, and Copenhagen.

Product Owner certification teaches you how to use the Scrum product backlog as a tool for project success.

7 courses scheduled in Austin, Silicon Valley, Orange County, Dallas, London, Colorado, and Copenhagen.

This agile training shows you how to go about agile estimating and planning, and why it’s crucial even in a fluid and iterative process.

Offered as an on-site course. Available as a video training course.

Go beyond the basics and learn tips and techniques necessary to help an organization move beyond initial success to sustained agility.

Offered as an on-site course.

This agile training teaches what makes a great user story, what makes a bad one, and how to achieve the six important attributes of a good story.

Offered as an on-site course.

ScrumMasters and their teams will learn how to overcome the most common and vexing Scrum challenges with this online troubleshooting course.

Available as a video training course.

Watch Mike Cohn’s popular conference keynote session and learn how holding onto views may be holding you back.

Available as a video training course.

Overcome the challenge of writing user stories to join the ranks of high-performing agile teams, deliver the right products to market, and delight your customers.

Available as a video training course.