Join 71,485 others and receive one short tip to improve your use of agile or Scrum direct to your inbox each Thursday.
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.
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.
Vital to the Scrum process are the roles taken on by individuals and team members. These pages go into greater detail about those major roles.
The product owner is the project’s key stakeholder. Typically, the product owner will be the primary user of the product, or at least have a deep understanding of who will. Despite this expertise, the product owner does not get to determine how much work happens in the sprint cycles, or alter the goals for that sprint. Product owners must be available to the team, and engage actively with it. Communication is a huge part of this, as the product owner communicates with both the team and other stakeholders.
The Scrum Master is the person who ensures the team keeps to the values and practices of Scrum, sort of like a coach. They remove impediments, facilitate meetings and work with product owners. Interestingly, the Scrum Master is a servant-leader who doesn’t have authority over the team, but does have authority over the process. They can’t fire people, but they can alter how long the sprints are. This can make the role more challenging than a traditional management role.
In a Scrum team, everyone works together to do whatever it takes to complete tasks they’ve all agreed on for a sprint. The Scrum team might have five to nine people on it. When projects are larger, you work with teams of teams, rather than making larger teams. In this case, teams may designate one member to attend meetings with people from other teams for something analogous to the daily Scrum, though it only takes place every few days. This section includes a helpful diagram of such a scenario.
The chicken and the pig story illustrates the difference between team member commitment and team member involvement. Without giving it away, we’ll just say that the pig isn’t interested in working with someone who wants to be involved, but not committed.
Scrum meetings happen at particular points in the sprint cycle. These pages will guide you through setting up regular meetings with your team.
Prepare for daily meetings with the daily Scrum meeting. The “daily Scrum” is meant to be consistent – same place and time each day, preferably in the morning. Further, they are meant to be no longer than 15 minutes. The meeting is for the entire team, including the Scrum Master and product owner. It’s important that the meeting is more about status updates than problem solving, which should be solved with appropriate subgroups. Further, the status updates are not to inform the boss on who’s behind, but to keep team members committed to one other. It’s also a way for the Scrum Master to learn about impediments that need addressing.
The sprint planning meeting is another meeting for the entire team. In these, the product owner lays out the highest priorities of the product (enough for two sprints), and the team asks questions that will help break the big concepts into detailed tasks. The idea is to come away from the meeting with both a sprint goal (a short description of achievement goals) and a sprint backlog (list of product features to be delivered and the tasks to make that happen). It’s up to the team, not the product owner, to determine how much work they can do in the coming sprint.
In the sprint retrospective meeting, you reach a point when the Scrum team looks for ways to improve in the wake of a sprint. Once again, this is for the whole team, and can usually happen in about an hour. We recommend structuring the meeting around what the team should start doing, stop doing and continue doing. This is simple and effective, and can be customized to individual teams. The Scrum Master can facilitate and even ask for a vote on items brought up by the team.
The sprint review meeting discusses the actual product produced at the end of a sprint. This is the actual piece of software or product that can be demoed in an informal way. The final product is also measured against the original sprint goals. The overall goal is more important than getting to every product backlog item in the sprint.
To be successful with Scrum and get as much as you can out of every cycle, these tools can help. In this section, we cover the different types of artifacts and provide examples that illustrate their use.
The Scrum product backlog is a list of features desired for a final product. The product backlog is typically more than can be accomplished in one sprint, and will most likely evolve as teams learn more about the product and the client. Product backlogs usually examine a product’s features and bugs, as well as technical work and knowledge acquisition. This section goes into greater detail about each of these, touching on user stories and giving examples.
The release burndown chart tracks progress on a Scrum project. The chart itself is updated after each sprint. Teams can measure progress in any unit they choose. For example, you can track sprint progress by story points, days, teams, etc. This section provides a great visual example, as well as an example of an alternative version.
The sprint backlog is simply a list of tasks to complete during a sprint, though the tasks do revolve around product backlog items. You have options for how to maintain your sprint backlog, including a spreadsheet or tracking software. Usually, the backlog will be updated once a day or so. This section also discusses how teams may tweak the sprint backlog as sprints move forward.
The Scrum task board is something that every member of the team can use and add to over the course of a sprint, and is a visual representation of every task and what phase of completion it’s in. Usually, task boards include columns for stories, to-dos, work in process, things needing verification and items finished. Some teams also include burndown charts, notes and tests. The task board itself might be physical and hanging on a wall, or it might be digital and in a shared network.
The Scrum resources section includes a Scrum overview with the major terms you’ll encounter every day in Scrum. You’ll also find a visual representation of the Scrum cycle, breaking the process into backlogs, sprints, meetings and shippable products. Within each cycle is time for the team to decide how much they can realistically accomplish during the sprint.
Our resources section also includes a reusable Scrum presentation section. Along with another helpful graphic to illustrate Scrum, you’ll find multiple formats of an introductory presentation, which is fully redistributable. The presentation is also available in several different languages.
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 page will not be seen. Going to https://www.mountaingoatsoftware.com/exclusive will redirect to the homepage.
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.
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.
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.