Project Management Statistics 2018

 

Stats can mean the difference between a successful project and project failure, with multiple jobs and millions of dollars on the line.

As a project manager, you need to interpret the numbers—budgets, timelines, KPIs—to determine when things are headed in the right direction and when changes need to be made. For example, when is it time to upgrade from free project management software to paid software?

I crawled the internet for up-to-date project management research, and found ten stats to help guide your 2018 strategy.

10 project management statistics for 2018

1. A lack of clear goals is the most common factor (37%) behind project failure, according to executive leaders.
(Source: PMI Pulse of the Profession 2017)

The takeaway:  Avoid project failure by having a project kick-off meeting before doing anything else.


2. Only 37% of teams in the U.K. reported completing projects on time more often than not. 
(Source: Wellingtone)
The takeaway:  Delays are inevitable, but that doesn’t mean you should accept that every project will be behind schedule. Use Gantt charts to stay on schedule as much as possible.

3. 73% of U.S. workers think that technology can never replace the human mind. 
(Source: PricewaterhouseCoopers)
The takeaway:  Artificial intelligence is already changing project management, but that doesn’t mean that PM jobs will be replaced by robots. In the 21st century, soft skills—like communication and leadership—will be even more important than hard skills, like using spreadsheets and presentation software.

4. As of March 15, 2018, the average project manager salary nationwide is $80,854. 
(Source: Glassdoor)
Project management statistics for 2018: Average project manager salary
Glassdoor
The takeaway:  Project management can be a lucrative career choice.

5. Between 2015 and 2016, the percentage of organizations using a spreadsheet to manage their Agile projects decreased from 74% to 67%.
(Source: VersionOne)
The takeaway:  A spreadsheet can be great for managing your personal finances, but it’s not designed for managing Agile projects. There are apps for that.

6. 85% of firms have a PMO (project management office), up 5% from 2014. Almost half (45%) of PMO staffers have earned their PMP (Project Management Professional) certification. (Source: The State of the Project Management Office (PMO) 2016\\
The takeaway:  A project management office has become a necessity rather than a luxury at high performing organizations. A PMP certificate, on the other hand, is nice to have, but not required.

7. 90% of companies said that open source software increased efficiency, interoperability, and innovation. Use of open source software increased at 65% of companies in 2016.
(Source: Black Duck Software)

The takeaway:  You don’t have to pay for project management software. You do need to be aware of the risks, though. Free software often has less features than paid software, and open source solutions can require an experienced IT team to run them.


8. Managing project costs (49.5%) was the biggest problem faced by manufacturing project managers in 2017. Hitting deadlines (45.8%) and sharing information across teams (43.9%) weren’t far behind.
(Source: Liquid Planner)
The takeaway:  Time management, budget management, and communication continue to form the foundation of good project management. Get those things right, and success will follow.

9. More than half (56.6%) of manufacturers use a combination of project management methodologies.
(Source: Liquid Planner)

The takeaway:  There’s no magic bullet when it comes to project management methodologies. Rather than rigidly subscribing to Agile or Waterfall, the best project managers continue to study and learn, and use the techniques that work best for their teams, regardless of which school of thought those techniques come from.


10. 59% of U.S. workers say communication is their team’s biggest obstacle to success, followed by accountability (29%).
(Source: Atlassian)

The takeaway:  More than half of all projects fail because of a breakdown in communications. Whether your teams are all in the same location or on separate continents, as the project manager it’s your responsibility to foster communication. Collaboration and web conferencing tools can make this job easier.

Project management is more than just numbers

It’s fun to look at statistics, but the more important thing is what you do with these numbers. These takeaways can help you refocus your strategy. If you enjoyed this piece, share it on social media (bonus points for mentioning me on Twitter, @consultantwww)

To keep up with the latest in project management technology trends, bookmark Think Tank – infoictionary.

Advertisements

Scrum

Scrum is one of the most popular frameworks for implementing agile. So popular, in fact, that many people think scrum and agile are the same thing. (They’re not.) Many frameworks can be used to implement agile, such as kanban for example, but scrum has a unique flavor because of the commitment to short iterations of work.

What’s so special about scrum?

With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a framework for shipping software on a regular cadence. Milestones–i.e., the end of a sprint–come frequently, bringing with them a feeling of tangible progress with each cycle that focuses and energizes everyone. (“Continuous inspiration” for the win!) Short iterations also reinforce the importance of good estimation and fast feedback from tests–both recurring struggles in waterfall projects.

Scrum calls for four ceremonies that bring structure to each sprint:

  • Sprint planning: A team planning meeting that determines what to complete in the coming sprint.
  • Daily stand-up: Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync.
  • Sprint demo: A sharing meeting where the team shows what they’ve shipped in that sprint.
  • Sprint retrospective: A review of what did and didn’t go well with actions to make the next sprint better.

During a sprint, visual artifacts like task boards and burndown charts, visible to the team and spectators alike, are powerful motivators. They drive a spirit of “we’re doing this!” Having the opportunity to show off new work at the sprint demo is equally motivating, and the consistent, incremental feedback the team gets from stakeholders at each demo creates a powerful way to develop products.

Scrum Burndown chart | Atlassian agile coach

Scrum done well–which is to say, not “waterfall with stand-ups”–can be a massive catalyst for improving team productivity and morale, and the product development process as a whole.

Three essential roles for scrum success

A scrum team has a slightly different composition than a traditional waterfall project, with three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, “the development team” includes testers, designers, and ops engineers in addition to developers.

The product owner

Product owners are the champions for their product. They are focused on understanding business and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:

  • Build and manage the product backlog
  • Closely partner with the business and the team to ensure everyone understands the work items in the product backlog
  • Give the team clear guidance on which features to deliver next
  • Decide when to ship the product with the predisposition towards more frequent delivery

Keep in mind that a product owner is not a project manager. Product owners are not managing the status of the program. They focus on ensuring the development team delivers the most value to the business. Also, it’s important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.

The scrum master

Scrum masters are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

Scrum masters also look to resolve impediments and distractions for the development team, insulating them from external disruptions whenever possible.

Part of the scrum master’s job is to defend against an anti-pattern common among teams new to scrum: changing the sprint’s scope after it has already begun. Product owners will sometimes ask, “Can’t we get this one more super-important little thing into this sprint?” But keeping scope air tight reinforces good estimation and product planning–not to mention fends off a source of disruption to the development team.

Scrum masters are commonly mistaken for project managers, when in fact, project managers don’t really have a place in the scrum methodology. A scrum team controls its own destiny and self-organizes around their work. Agile teams use pull models where the team pulls a certain amount of work off the backlog and commits to completing it that sprint, which is very effective in maintaining quality and ensuring optimum performance of the team over the long-term. Neither scrum masters nor project managers nor product owners push work to the team (which, by contrast, tends to erode both quality and morale).

The scrum team

Strong scrum teams approach their project with a strong “we” attitude.

Scrum teams are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. All members of the team help one another to ensure a successful sprint completion.

As mentioned above, the scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

But wait: there’s more

Ok: so now you’ve been briefed. But understanding the philosophy of scrum and who is on a scrum team is only half of the equation. Keep reading to learn how scrum team members work together using common agile ceremonies as well as how the team in an agile program delivers work back to the business.

What is agile project management?

How agile methodologies can work for your software team

Software teams have been embracing agile project management methodologies for nearly a decade, increasing their speed, collaboration, and ability to respond to market trends.

But what is it, and can it help your software team? Here is everything you need to know to get started, or refine, your agile project management practices.

History

Agile project management is an iterative approach to managing software development projects that focuses on continuous releases and incorporating customer feedback with every iteration.

Stemming from Toyota’s lean manufacturing concept of the 1940s, software development teams have embraced agile methodologies to reduce waste and increase transparency while quickly addressing their customers’ ever-changing needs. A stark change from waterfall project management that focuses on “big bang” launches, agile helps software teams collaborate better and innovate faster than ever before.

Traditional agile project management can be categorized into two frameworks: scrum and kanban. While scrum is focused on fixed-length project iterations, kanban is focused on continuous releases. Upon completion, the team immediately moves on to the next.

How scrum works

Scrum is a framework for agile project management that uses fixed-length iterations of work, called sprints. There are four ceremonies that bring structure to each sprint.

It all starts with the backlog, or body of work that needs to be done. In scrum, there are two backlogs: one is the product backlog (owned by the product owner) which is a prioritized list of features, and the other is the sprint backlog which is filled by taking issues from the top of the product backlog until the capacity for the next sprint is reached. Scrum teams have unique roles specific to their stake in the process. Typically there’s a scrum master, or champion of the scrum method for the team; the product owner, who’s the voice of the product; and the scrum team, who are often cross-functional team members in charge of getting a…z done.

The four ceremonies of scrum

Sprint Planning Sprint Demo Daily Standup Retrospective
A team planning meeting that determines what to complete in the coming sprint. A sharing meeting where the team shows what they’ve shipped in that sprint. Also known as a stand-up, a 15-minute mini-meeting for the software team to sync. A review of what did and didn’t go well with actions to make the next sprint better.

 

Scrum board example | Atlassian agile coach

The scrum board

A scrum board is used to visualize all the work in a given sprint. During the sprint planning meeting, the team moves items from the product backlog into the sprint backlog. Scrum boards can have multiple steps visible in the workflow, like To Do, In Progress, and Done. Scrum boards are the key component for increasing transparency in agile project management.

How kanban works

Kanban is a framework for agile project management that matches the work to the team’s capacity. It’s focused on getting things done as fast as possible, giving teams the ability to react to change even faster than scrum.

Unlike scrum, kanban has no backlogs (usually). Instead, work sits in the To Do column. This enables kanban teams to focus on continuous releases, which can be done at any time. All work is visible, scoped, and ready to execute on so that when something is completed, the team immediately moves on to the next. The amount of work is matched to the team’s capacity through WIP limits, which is a predefined limit of work that can be in a single column at one time (except the To Do column). The kanban framework includes the following four components:

The four components of kanban

List of work 
(or stories)
Columns or lanes Work in Progress Limits (WIP) Continuous Releases
List of work, or stories, are defined as issues or tasks that need to get done. Used on a kanban board to distinguish tasks from different workstreams, users, projects, etc. A rule to limit the amount of work to be done based on the team’s capacity. The team works on the amount of stories within the WIP limit and can release at anytime.

 

The kanban board

A kanban board is used to visualize all the work that’s being done. It’s also used for planning resources allowing project managers to see the work and develop timelines accordingly. A kanban board is structured into columns and lanes that stories pass through on their way to completion. Stories sit in the To Do column until the WIP limit allows for the next task to be worked on. The list of work should be split into relatively small issues and organized by priority. As you can see in this example, lanes can help keep the higher priority items separated from “everything else.”

Estimate, report and plan

Whatever agile framework you choose to support your software development, you’ll need a way to see your team’s progress so you can plan for future work or sprints. Agile project estimating helps both scrum and kanban teams understand their capacity. Agile reports show the team’s progress over time. And backlog grooming helps project managers keep the list of work current and ready for the team to tackle.

Agile project estimating

Project estimating is an extremely important aspect of both kanban and scrum project management. For kanban, many teams set their WIP limit for each state based on their previous experiences and team size. Scrum teams use project estimating to identify how much work can be done in a particular sprint. Many agile teams adopt unique estimating techniques like planning poker, ideal hours, or story points to determine a numeric value for the task at hand. This gives agile teams a point of reference to refer back to during sprint retrospectives, to see how their team performed.

Agile reporting

Project estimations come into play at the beginning and end of each sprint. They help teams determine what they can get done at the beginning of the sprint, but also show how accurate those initial estimates were at the end. Agile reports, such as Burndown charts, show how many “story points” are completed during the sprint. Having data to support your retrospectives is an invaluable way for agile teams to improve.

Backlog management and grooming

A product backlog is a prioritized list of work for the development team to do that comes from product roadmap and its requirements. The development team pulls work from the product backlog for each sprint.

Grooming and maintaining your backlog helps teams achieve their long-term goals by continually adding and removing items based on the team’s long-term capacity and changing business objectives. Jira Software lets teams groom huge backlogs with multi-select ranking and order user stories and bugs by dragging and dropping issues. You can also filter with Jira Software’s flexible search to find a particular user story or bug.

Scrum agile project management

This is your go-to guide on scrum, a popular agile project management framework. You’ll learn scrum terminology, how to use the methodology in software and product development projects, and more.

There are so many agile project management frameworks that it can be difficult for newcomers to the field to get a good grasp of each one. Here’s a quick introduction to scrum, which is one of the most popular agile methodologies.

This resource guide is intended to be useful for project managers, business leaders, developers, project and product teams, consultants, stakeholders, and students. We’ll update this primer when new information is available about scrum.

SEE: All of TechRepublic’s smart person’s guides

Executive summary

  • What is scrum agile project management? Scrum is a popular iterative software development framework that is often used to manage product development. It uses short, iterative cycles called sprints to complete work.
  • Why does scrum agile project management matter? This agile framework is highly adaptable due to its simplicity, its flexibility, and the learning opportunities available to leaders and teams, who also benefit from the high degree of customer satisfaction.
  • Who does scrum agile project management affect? Project leaders, teams (made up of a scrum master, a product owner, and a scrum team), developers, stakeholders, end users, the business as a whole, and ultimately clients.
  • When is scrum agile project management happening? Scrum has been applied as a methodology since 2001 and is now one of the most widely used agile frameworks within various companies and industries worldwide.
  • How do I use scrum agile project management? There are numerous online resources, which include the Scrum Alliance founded in 2002 by Ken Schwaber and others; Scrum Guides, which were started by Ken Schwaber and Jeff Sutherland; and various organizations, including PMI and Scrum.org, that provide in-depth background information about the framework, as well as training and certification options.

SEE: IT leader’s guide to Agile development (Tech Pro Research)

What is scrum agile project management?

The word scrum originated from a rugby analogy in a 1986 study by Hirotaka Takeuchi and Ikujiro Nonaka, and is just one of the many agile frameworks used in project management to improve quality and expedite product development and delivery. There are three key roles in scrum: the scrum master, the product owner, and the development team.

  • The scrum master takes on the role of a coach/team leader who is responsible for overseeing and guiding the process and making sure the team meets its goals and deliverables. Although the team is self-organizing, the scrum master works with the team to ensure there is synergy and alignment in their focus.
  • The product owner is, in essence, a project sponsor who develops the wish list of things to be done and prioritizes it. The product owner interacts with the team and the scrum master throughout the project.
  • The Scrum team is a self-organizing collaborative team that is used across functions and brought together because of their relevant and necessary skills for a project. This team of usually 5 – 10 people has the full capabilities and authority to complete the work and determines their tools and techniques as well as the delegation of work.

There are core terms in scrum you should know.

  • Artifacts: Product backlog, sprint backlog, etc.
  • Burndown chart: Displays the work effort that remains over a timeline.
  • Burnup chart: Displays the increase in a measure against time.
  • Definition of done (DoD): A set of expectations defined by the development team that outlines when a product is releasable.
  • Scrum team: A small team of 5 – 10 members that manages and completes the work within each sprint required to release a product to the customer.
  • Product owner: The person who manages and communicates all requirements for a product to maximize value for the customer.
  • Scrum board: The scrum team uses this physical board to diagram information needed to complete work.
  • Scrum master: A coach/team leader who is responsible for overseeing and guiding the process and making sure the team meets its goals and deliverables.
  • Sprint: A 2- to 4-week time frame increment that teams work within to complete the required work. There are usually iterations within a project.
  • Sprint backlog: A high-level view of work to be done to realize a sprint goal.

Additional resources:

Why scrum agile project management matters

Scrum offers project teams and organizations the following benefits.

  • Because scrum has a predetermined set of role, rules, and processes, it provides teams with an easy to implement process for getting work done, measuring success, and gaining higher levels of customer satisfaction.
  • Teams get to continually hone their skills and enhance their knowledge to maintain quality standards, meet stakeholder requirements, and improve collaboration.
  • Quality is mandated and defined within the DoD as a primary requirement before a product can be released. This increases the likelihood of success.
  • Scrum is highly flexible, as sprints do not impact work that was previously done in project phases, and instead executes only the work in the current sprint, offering teams greater focus.
  • Team collaboration and cohesiveness levels tend to be higher, as teams are self-organizing.
  • Costs are usually more contained.

Additional resources:

Who scrum agile project management affects

More for CXOs

The use of scrum benefits all members of a project team, including developers, project and product managers, testers, engineers, system designers, technical writers, and executives. The largest benefit is passed onto the customer through faster debugging, less frequent defects, and quicker turnaround of high-quality products.

Additional resources:

When scrum agile project management is happening

In the Scrum Alliance’s 2015 State of Scrum Report (PDF), 60% of scrum teams adhere to the 7-person team size and 2-week sprints, while 81% hold daily team meetings and 83% plan before each sprint. Further, 90% make use of some form of scrum artifacts, and approximately 56% say artifacts are widely used. Scrum continues to increase in popularity and practice.

Additional resources:

How to use scrum agile project management

During each sprint, the scrum team works together with the development team, which starts by looking at the wish list that was put together and prioritized by the product owner or backlog and plans how to tackle the tasks within a two- to four-week increment.

  1. The team develops tasks and delegates each of the tasks.
  2. The team identifies all deliverables.
  3. The team updates the backlog status.
  4. The team develops a new burndown chart.

You can achieve even greater benefits when using scrum with other frameworks such as Kanban and lean to create a hybrid solution.

Additional resources:

ACCEPTANCE CRITERIA

DID WE BUILD THE RIGHT PRODUCT? AND, DID WE BUILD THE PRODUCT RIGHT?

Acceptance Criteria are important.  Unfortunately, we often overlook or undervalue it as an aspect of the iterative planning process. It is super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceivedacceptance criteria. When we clearly define the criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction.  In other words we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?

WHAT ARE ACCEPTANCE CRITERIA?

They are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.

Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.

We’re not talking about horseshoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.

WHEN TO DEFINE OUR ACCEPTANCE CRITERIA?

A trap that I encourage my teams to avoid is writing acceptance criteria after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations. If we write and review the criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.

WHAT MAKES GOOD ACCEPTANCE CRITERIA?

Acceptance criteria define when a work item is complete and working as expected. Express criteria clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they will be taking our criteria and translating them into automated test cases to run as part of our continuous integration build.

WHAT. NOT HOW.

Another trap that I coach my teams to avoid is the how trap. Criteria should state intent, but not a solution. (e.g., “User can approve or reject an invoice” rather than “User can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT to expect, and not HOW to implement the functionality.

FORMATS

The Given/When/Then format is helpful way to specify criteria:

Given some precondition When I do some action Then I expect some result

When writing acceptance criteria in this format, it provides a consistent structure. Additionally, it helps testers determine when to begin and end testing for that specific work item.

Sometimes it’s difficult to construct criteria using the given, when, then, format. Particularly when dealing with system level user stories. In those cases, I’ve found that using a verification checklist works well.

Another advantage to verification checklists is that they are also simple to individually mark as complete as we implement functionality.

SIMPLE CHEAT SHEET TO SPRINT PLANNING MEETING

WHAT IS SPRINT PLANNING?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of product backlog items.  This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

WHO DOES IT?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

HOW DO WE PREPARE?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

  • Assign a relative story point value
  • Remove dependencies
  • Create testable examples
  • Define acceptance criteria
  • Meets INVEST criteria

WHAT IS THE BACKLOG?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

ENSURE RIGHT SIZING BACKLOG ITEMS

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

CALCULATING A COMMITMENT

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

DETERMINING VELOCITY

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

DETERMINING CAPACITY

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

THE PLANNING STEPS

  1. Remind the team of the big picture or goal
  2. Discuss any new information that may impact the plan
  3. Present the velocity to be used for this release
  4. Confirm team capacity
  5. Confirm any currently known issues and concerns and record as appropriate
  6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
  7. Present proposed product backlog items to consider for the sprint backlog
  8. Determine the needs, sign up for work, and estimate the work owned
  9. Product Owner answers clarifying questions and elaborates acceptance criteria
  10. Confirm any new issues and concerns raised during meeting and record
  11. Confirm any assumptions or dependencies discovered during planning and record
  12. ScrumMaster calls for a group consensus on the plan
  13. Team and Product Owner signal if this is the best plan they can make given what they know right now
  14. Get back to work

A Guide To Sprint Planning Meeting

Sprint Planning Meeting

A sprint planning meeting is conducted before the start of a sprint. The purpose of this meeting is to determine the sprint plan and set a sprint goal. This meeting is split into two sessions. In the first session, the product owner reviews the list of features and defines what needs to be built during the next sprint. The next session involves identification of tasks that need to be executed, in order to complete the build.

Importance of Sprint Planning

The sprint planning meeting should yield the sprint objective and the sprint backlog. This defines the tasks that need to be completed and also the time estimates for tasks. The scrum team becomes aware of what needs to be done and how to do it.

Preparation

1. The right people

It is important to have one person wholly dedicated to the product as the product owner. He should be an able communicator and understand what is required of the product. Also nominate the scrum master, who will mentor the team. Everyone on the project development team should be involved in the sprint planning process.

2. Product Backlog

The product backlog contains everything related to the product such as improvements, bugs and issues. Encourage everyone on the team to add to the backlog. However, prioritizing items on the backlog should be done only by the product owner.

During the meeting

1. Determine the goal

The goal is collaboratively determined from the highest priority items on the product backlog. Looking at previous sprints can help derive a better time estimate. A few items can be designated as stretch tasks that can be taken up if the team finishes early.

2. Break items into tasks

The requirements for each product backlog item is considered and it is broken down into tasks. Determine the estimate for these tasks in hours.

3. Commit to the sprint backlog

Compare the total of all the task estimates with the number of hours available (the sprint budget). Remove low priority items, if the estimate exceeds the sprint budget. This yields the sprint backlog.

 
Sprint Planning Meeting Template

Mistakes to avoid in a sprint planning meeting

1. Too much focus on getting the perfect task estimate

Teams should instead focus on the right items from the product backlog to work on during the sprint.

2. Don’t start without a product backlog

A detailed and thorough product backlog will drive high velocity and high value delivery. Ensure that it is ready before proceeding to the sprint planning phase.

3. Don’t meet without the product owner present

The product owner has to be available and committed to the sprint planning process.