Agile Teamwork: How Great Teams Deliver

Learn about agile teams and agile teamwork—central components of any agile framework, including Scrum.

What Is Agile Teamwork?

Agile teamwork is when a small group of people work together to solve a compelling problem.

Hackman’s 2011 study “Collaborative Intelligence: Using Teams to Solve Hard Problems” asserts that “interdisciplinary and even inter-organizational teams are necessary to solve really hard problems.”

Why Teamwork Is Important for Agility

Teamwork matters for agility because teams are the heart and engine of an agile way of working.

Working as a team is essential to delivering a potentially shippable piece of value to customers at the end of an iteration. Teamwork is so important that the Agile Manifesto describes it in at least three different principles:

• Why Encourage Collaboration? “The best architectures, requirements, and designs emerge from self-organizing teams.”
• Why Prioritize Conversations? “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
• Why Nurture Culture? “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

How to Build Effective Teams

Teamwork is perhaps best described by the six conditions for team effectiveness, as defined by years of research from Richard Hackman and Ruth Wageman. They define three essentials and three enablers of teamwork.

Three Teamwork Essentials

• The ideal agile team structure includes the right people, with the diverse skills and perspectives necessary to accomplish the work.
• A true team is defined, works together to accomplish a goal, and is stable.
• A compelling purpose engages the team and points them in a shared direction.

Three Teamwork Enablers

• A sound culture enables each agile team to thrive. (Ensure each team is the right size, has defined norms, and has work that “makes sense to do as a team.”) Teams in an agile environment also need opportunities for team building.
• Team coaching helps each team optimize its resources, understand the various roles, cultivate an agile mindset, and recognize the mechanics and intent behind their chosen agile process and behind each agile practice.
• Structures and systems that promote agile principles and support great teamwork, including rewards for team performance.

How Is Agile Collaboration Different from Teamwork?

Agile collaboration is one essential ingredient in teamwork, but teamwork is about more than just being collaborative.

Teamwork is about being accountable and striving for improvement. It is being purposeful about maximizing the flow of work through the team.

Free Resources: How an Agile Team Works

Working as an Agile Team

Good teams don't just happen. Without a clear problem to solve together, a cross-functional approach, and a sense of camaraderie, a team is only a group of people.

Agile software development teams learn how to make handoffs small, how to do a little bit of everything throughout the iteration, and how to bring in the optimal mix of product backlog items to make collaboration possible.

Make Handoffs Small

On teams using an agile methodology like Scrum, the unit of transfer between team members should be smaller than a product backlog item (typically, a user story). That is, although there will always be handoffs, you want them to be as small and frequent as possible.

An Example of Small Handoffs

Suppose an agile team is developing a new eCommerce application. The team chooses to work on this user story from its product backlog: As a shopper, I can select how I want items shipped based on the actual costs of shipping to my address so that I can make the best decision.

At the beginning of the iteration, members of the agile development team begin to discuss some of the general needs implicit in this feature:

• Which shipping companies (FedEx, UPS, etc.) do we support?
• Do we want to support overnight delivery? Two-day delivery? Three-day delivery?
• Are we going to charge a handling fee? On all items? A fixed amount or a sliding scale?

Once the agile team brings this backlog item into an iteration, the team members (developers) who anticipate working on it discuss where to begin with the product owner. Here that would include:

• The product owner
• An analyst who will get answers to the open issues
• One programmer
• One tester

Naturally, some backlog items will require more people or more than one programmer or tester.

Team Collaboration During a Sprint

Let's suppose this group of team members meet and agree to start by developing support for FedEx first. The programmer can begin designing, coding and unit testing support for FedEx.

While the programmer begins that, the product owner, analyst and tester discuss any high-level acceptance criteria that have not already been identified.

The tester can turn the acceptance criteria into automated tests. The analyst will work to get answers to the open issues. As the analyst does that, answers are communicated to the tester and programmer who will incorporate them into their work.

When the programmer and tester are both done, and the code passes the automated tests, the new functionality is added into the official build of the product. Ideally it is deployed as well.

The programmer and tester then work on adding support for UPS and add that to the build when done.

The Ideal Size for Handoffs

When teams are new to agile and Scrum, they tend to make handoffs too big. For example, the programmer might grab a product backlog item and finish all of the work on it before handing it over to a tester.

Work will flow more smoothly if the programmer instead hands work over each time an additional acceptance criteria or test is ready for validation by the tester. It’s possible this is too small to be practical in some cases (especially with globally distributed teams). However, it’s good to keep this size in mind as a goal.

Do a Little Bit of Everything

The agile team in the example I just discussed has learned to work by doing a little of everything all the time. They are embracing an agile approach to work. 

At the beginning of an agile transformation, many new teams struggle with this concept. They might work in iterations, but inside the sprint, they continue to approach work in phases: an analysis phase followed by a programming phase followed by a testing phase.

Signs Your Agile Team Might Be Stuck in a Phased Approach

• Does your team have a tendency to only finish product backlog items on last few days of the sprint?
• Are your testers complaining that they are given nothing to test until two days before the end of a sprint and then are expected to test everything quickly?

A good way to expose this problem is to create a chart of the number of product backlog items finished as of each day in the sprint. Here is an example:

For a collocated team, I like to hang this in the team area with no fanfare or explanation. Team members will notice the problem and, hopefully, start to find ways to finish product backlog items sooner.

For a distributed or remote team, I like to have this included on a product home page if team members regularly use a tool that can show this type of graph. If not, the Scrum Master can share their screen at the start of each daily scrum, along with any other information team members like to have visible during the meeting.

Include Backlog Items of Different Sizes

Doing a little bit of everything all the time and minimizing handoffs is easier with the right mix of product backlog items. During the sprint planning meeting, teams should pay attention to the sizes of the product backlog items they bring in.

For some product backlog items it will be difficult to create small handoffs. That’s fine. But you don’t want to plan a sprint with nothing but that type of item. If you did, it would likely shift too much testing to the end of the sprint.

Avoid that by bringing in some smaller product backlog items that can be handed off in multiple smaller pieces.

How to Encourage Teamwork

A team's agile coach /Scrum Master can encourage teamwork by helping teams understand how to break from their sequential work habits, foster open communication, and overlap work. Leaders in an agile organization can help by maximizing employees’ learning opportunities and giving teams the freedom to discover fresh ideas and approaches to problem solving.

Creating new teamwork habits can be challenging. Discover more about the many elements of teamwork.

Free Resources: Good Habits for Great Teams

Teamwork and Agility

Good teamwork and being a good team member are critical skills to learn—every bit as critical as learning to be a Scrum Master or product owner. Yet effective teamwork skills are so often overlooked, even by certifying bodies such as Scrum Alliance and Scrum.org.

That’s why we offer private courses, video courses, group public course discounts, and onsite mentoring for teams. We cover the basics of the Scrum framework for agile project management, including the Scrum roles, Scrum meetings (e.g. sprint planning, sprint review), and Scrum artifacts, such as product backlogs and sprint backlogs.

But just as importantly, we work on skills to help your agile team members work together to deliver value each and every iteration.

That’s also why we developed our own Working as a Scrum Team course, offered for one team, multiple teams, or even just one team member (through a public offering). Learn more about how we can help.

Thank you, we'll get in contact with you.

Thank You!

You can now close this page.

Working on a Scrum Team is a two-day course taught by world-class Scrum trainers personally selected and trained by best-selling agile author, Mike Cohn.

This course teaches the fundamental principles and practices of Scrum.

Register your interest and be the first to know when this course is available.

Join the Waitlist

Team Home is a collaboration platform that we designed for our courses. It is optimized for live, online training. Participants benefit by collaborating in ways beyond what is possible with generic whiteboard software such as Mural or Miro. Instructors can observe activity across all rooms, improving the effectiveness and efficiency of exercise debriefs.

 

A one-day, live, online class

If you need a concise, but actionable understanding of agile, this course is for you.

After just one day, you’ll have the confidence and knowledge you need to start embracing agile practices such as iterative development, customer collaboration and adapting to change.

Find out when places are available

Join the Waitlist

This one day course provides an introduction to agile and some of the most popular agile frameworks.

After the class you will:

• Understand the new roles on an agile team and how existing roles change
• Know how to work in short, timeboxed iterations to deliver value every couple of weeks
• Run effective, efficient agile meetings
• Overcome some of the most common hurdles to becoming agile

Find out when places are available

Join the Waitlist

Course Topics

• Overview of Agile - Understand the principles of agile and the basics of different agile approaches including Scrum and Kanban
• Working in Iterations - Explaining why they are timeboxed, require collaboration, and completed work in every iteration
• Roles on an Agile Team - An overview of the key roles in agile including how existing roles change when you move to agile
• The Product Backlog - What should be on the backlog, and how to maintain it
• Iteration Planning Meeting - Its purpose and how to approach it
• Iteration Review Meeting - Who should attend and what do you do? Iteration retrospective - Continually improving the process
• Daily Meetings - The purpose and troubleshooting common problems
• Challenges Introducing Agile - How to anticipate potential challenges

What You Get

• 6 hour training session live, online via Zoom
• A PDF of the course slides
• A one-year membership in the Agile Mentors Community
• Recordings of the live sessions and a PDF of all course exercises
• Completion credential and profile in our Agile Professional Directory

Join the Waitlist

Thank you for your feedback, it has been recorded.

Sprint Planning Definition

Sprint planning is a time set aside at the beginning of each sprint for the Scrum team to decide what work they will complete in the upcoming iteration. During a sprint planning meeting, Scrum and agile teams accomplish three things:

1. Discuss how to implement a set of product backlog items
2. Determine which set of product backlog items the team can commit to complete during the sprint (or iteration). These items and their tasks become the sprint backlog.
3. Choose and fine-tune the sprint goal to reflect the work of the sprint.

Getting Started with Sprint Planning (Part of our free Scrum Foundations video series.)

What Is the Goal of Sprint Planning?

The purpose of sprint planning is 1) to select the right set of product backlog items to work on during the sprint and 2) to discuss each item enough to feel confident beginning work.

Sprint planning is a time for the team to consider how they will approach doing what the product owner has requested. By contrast, story-writing workshops are when the product owner, stakeholders, and team brainstorm what functionality the customer needs most.

By the end of sprint planning, the team selects how much work they can do in the coming sprint. The product owner does not get to say, "We have four sprints left so you need to do one-fourth of everything I need." It's up to the team to determine how much they can do in the sprint.

Stop Playing It Safe: An Agile Team Shouldn't Finish Everything Every Iteration

Who Attends Sprint Planning?

The sprint planning meeting is attended by the entire Scrum team, including the product owner, Scrum Master. Outside stakeholders may attend by invitation of the team, although this is rare.

How Long Does Sprint Planning Take?

How long sprint planning lasts depends on the sprint length.

The official answer from the Scrum Guide is that sprint planning can take no more than 8 hours (usually less for shorter sprints).

Eight hours is far too long to spend planning.

Instead, target about 45 minutes of meeting time multiplied by the number of weeks in the sprint. So a two-week sprint should have a 90-minute sprint planning meeting. And a full four-week sprint (or one month sprint) should target a 3-hour sprint planning timebox.

It's OK if a team's first few planning meetings take a bit longer than this. In fact, it’s likely they will. But 45 minutes times the number of weeks is a good target for a team with a bit of experience.

If your teams are taking too long to plan, it's likely you are making one of the classic sprint planning mistakes: trying to identify every last task.

Comprehensive task lists and precise estimates are not the goal of sprint planning meetings. The purpose of sprint planning is to select the right set of product backlog items and have a rough idea of how to work on them. The team does not need to know every task they'll perform to accomplish this goal. And the team certainly does not need to know if one of those tasks will take 5 hours instead of 4.

What Happens in Sprint Planning?

During the sprint planning meeting, the product owner describes the highest priority features to the development team.

Then, sprint planning works in one of two general ways: by considering a team's historical velocity or by considering a team's capacity. Capacity planning is the better choice for sprint planning. Let's explore velocity and capacity planning to understand why this is true.

Capacity vs Velocity Based Planning

Capacity-driven planning starts with the product owner giving an overview of the set of high-priority items or user stories from the product backlog that could be brought into the sprint.

Team members select the first item. The team asks enough questions to understand what is required. They then break that item down into individual tasks.

Team members roughly estimate the hours (not story points) to do each task. Then, with their overall team capacity for the sprint in mind, they ask themselves if they can commit to deliver the product backlog item. (They remember not to overfill their sprint, because they know they can't think of every task during planning, and that's OK.)

If the answer is yes, they add that product backlog item and its tasks to the sprint backlog. They then ask themselves if they have enough capacity to consider another product backlog item.

If they do, team members grab the next most important product a backlog items from the product owner's list and repeat the process.

If the team decides they cannot commit to another product backlog item, they have several choices:

1. Look for ways to split a product backlog item into multiple, smaller size items

2. Choose a different product backlog item, or

3. Declare the sprint full.

During capacity-based sprint planning, there is no discussion of story points or velocity. It's just about determining the sprint commitment. The developers decide how much they can commit to by breaking product backlog items into tasks. They estimate each of these tasks in hours.

Contrast that with velocity-driven sprint planning. With velocity-based sprint planning, the team selects the number of product backlog items that equals their average velocity over time (historical velocity).

Some teams stop there. Others double check that they can commit to those items by breaking them down into tasks and estimating those tasks in hours to see if the amount of work is in line with past sprints.

Velocity Is Not Ideal for Sprint Planning

One problem with velocity-based sprint planning is that velocity bounces around from sprint to sprint. For example, suppose a basketball team is in the middle of their season. They've scored an average of 98 points per game through the 41 games thus far.

It would be appropriate for them to say "We will probably average 98 points per game the rest of the season." It would not be accurate for them to say before any one game, "Our average is 98 therefore we will score 98 tonight." Velocity is a useful long-term predictor but is not a useful short-term predictor.

That's just one of a couple reasons why capacity-driven planning is preferable to velocity-driven sprint planning.

Consider Flow of Work in Sprint Planning

Agile teams learn how to overlap work and minimize the size of handoffs between team members. Despite this, some product backlog items will require a week or more of programming time before the programmer can give something even beginning to be testable to a tester.

That’s OK. Not everything can be split as small as we might like.

To help ensure everyone has something to do early in the sprint and to avoid having multiple product backlog items wrap up the last few days of the sprint, good scrum teams learn to mix the size of product backlog items they bring into each sprint.

For example, a software development team might mix large-scale programming tasks with small, easy to implement items. That way, a few programmers can work on the smaller items, ensuring a smooth flow of work to testers early in the sprint. The rest of the programmers can work on the large items, handing them over to testers whenever possible.

Do Teams Have to Identify & Estimate Tasks?

Remember, when it comes to sprint planning in agile, the purpose is not to identify tasks. The purpose also is not to estimate the number of hours for each of those tasks.

The purpose of planning a sprint is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration.

Some teams split all work up such that all tasks are "about half a day." They then can skip explicitly estimating the hours for each task because, in a way they've already done it. But most teams need tasks and estimates to feel confident in making a commitment to a set of product backlog items.

Some amount of estimating and planning is necessary for all agile teams. The approach to these estimation activities can (and should) be as lightweight as possible.

Assigning Tasks During Sprint Planning

Ideally, teams leave sprint planning without having put names on tasks. Following a real-time sign-up strategy allows more flexibility during the sprint.

Starting a sprint without names on any tasks can be unsettling to teams and ScrumMasters who are new to Scrum. Start scaling back by asking people to sign up for only about half of the tasks in the sprint.

Do this for two sprints. After two sprints, have team members sign up for only one-fourth of the total tasks in the sprint. At this point, the team will start to see most of the benefits of a real-time sign-up strategy.

What Are the Inputs to Sprint Planning?

A refined and estimated set of product backlog items is the primary input to sprint planning.

New stories might have been added to the product backlog as a result of sprint review feedback. Different stories might exist on the product backlog after those stories were split. Estimates should be put on any new, high-priority stories prior to sprint planning. The product owner needs estimated product backlog items to prioritize.

A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint's worth of product backlog items.

Another input to sprint planning is either team capacity (if using capacity planning) or historical velocity (if using velocity planning methods).

What Are the Outputs of Sprint Planning?

There are two artifacts that result from a sprint planning meeting:

1. A sprint goal (Find out why sprint goals should be optional.)

2. A sprint backlog

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint and why it is valuable to stakeholders. It is written collaboratively by the team and the product owner. Sprint goals are not stretch goals.

The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of many of the tasks necessary to deliver those product backlog items. The sprint backlog can and will evolve during the sprint as the team learns more about the work being done. The team can and will add more tasks to their original list.

Find out how your team is progressing in their mastery of the 20 key Elements of Agile.

Take the free assessment

Find out how your team is progressing in their mastery of the 20 key Elements of Agile.

Each member of the Mountain Goat Software team is dedicated to giving you the best training, resources, and support you need, to succeed with agile. You can meet them here:

Looking for your course materials? Click here to login.

Looking for your course materials? Click here to login.

Looking for your course materials? Click here to login.

We offer volume discounts on purchases of 10 licenses or more.

Participating as a team means you can provide group training in a cost-effective manner designed to maximize shared learning.

The ability to access and reference the materials at your convenience makes it easy for large groups to learn together, without the complexity and cost of coordinating a live workshop.

Keep reading to see how to get your discount and group licenses.

It typically takes about 20 minutes for credentials to be generated - you'll receive those details via email.

Have questions? Send us an email.

---

Thanks for listening to John Callaway interview me for The 6-Figure Developer Podcast.

I’m here to help you succeed with agile development.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

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.

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.

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 activities happen at particular points in the sprint cycle. These pages will guide you through setting up regular meetings for these activitieswith 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.