Large Scale Scrum – LeSS

Product Owner

The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

Scaled Product Owner

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.

In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more customer focused.

In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.

Prioritization over Clarification

There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.

A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, she encourages and helps the teams enter into a direct conversation with true users and customers for clarification. She acts as a connector, not an intermediary.

Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.

It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.

Find a Product Owner Given Your Type of Development

Step 1: Know Your Development Type

Finding the right Product Owner depends on knowing the type of development you are doing:

  • Product development—For external customers or a market.
  • Internal (product) development—For one or more users within the company. The development group is usually called IT or Systems Development.
  • Project development—Usually for one external customer. The work is organized and contracted as a project of some kind although that does not necessarily mean a fixed scope/date/cost project contract. The development company is usually an outsourcer or systems-integrator. The customer, or client company, includes both the purchasing entity and the users, who are not always in the same department.

Step 2: Finding the right Product Owner

Product development—The company will have either (1) a business unit driving the product initiative (e.g., Retail Banking), or (2) a Product Management department driving the initiative. Traditional Product Management is responsible for customer and competitor analysis, product vision, coarse-grained feature selection and prioritization, product roadmap, and other non-technical activities. They don’t manage the work of a traditional development group.

Where to find a Product Owner for a group adopting LeSS? If there’s a Product Management department, then a Product Manager can be a good choice. Otherwise, look for a person from the business unit that’s driving the initiative. The important thing to keep in mind is that the Product Owner for product development should come from the business side.

Internal (product) development—A good Product Owner for internal product development in LeSS is (1) from within the group that will use the system, and (2) is closely involved in and deeply experienced in doing the real work that the system will support. They are very close to the real users.

Project development—The key point is that a Product Owner is from the company receiving the system and, as with internal development, is involved in and deeply experienced in the hands-on work, close to users.

A common variant for both internal and project development is when the system will be used by many departments. Then, a good choice is an experienced, hands-on individual from one of the major user departments who is interested in taking on the role and has political savvy.

The following figure shows the Product Owner in different organizations:

Who is the Product Owner in Different Types of Development

In all cases, a great Product Owner has a passion for the product.

When it is impossible to find the right Product Owner immediately, you can quickly start a LeSS adoption with a temporary Product Owner who understands what’s going on and can perform the mechanics of the role but is not from the business side. Let the teams complete several Sprints under the temporary Product Owner until the major kinks are worked out and — this is important — the development teams can deliver a truly ‘done’, shippable increment (or something close) every Sprint. Why? The product teams will be more likely to find and inspire the right longterm Product Owner if they can show a compelling new capability that offers very tangible business benefit. It’s terribly important that everyone understand that the temporary Product Owner is a placeholder. We often use the term “fake Product Owner” to indicate just how damaging this temporary Product Owner can be. Because the fake PO is not only not the best Product Owner but also she can cause damage trying to fill a role for which she is not qualified. She must be replaced as soon as possible to avoid the risk of creating a second-class product.

Step 3: Give Authority and Responsibility to a Real Product Owner

Product Owner is not a new name for a traditional project manager who delivers a scope and date contract of work. Rather, a Product Owner must have the independent authority to choose and change content, release dates, priorities, vision, etc. Of course she collaborates with stakeholders, but a real Product Owner has final decision-making authority.

Five Relationships

The Product Owner needs to understand and work to improve five key relationships that are affected by LeSS adoption:

Product Owner Relationships
  • Product Owner<–>Teams
    The teams are there to help the Product Owner create the best possible product for the customer. They need to know what to build next and whether or not what they have already built has hit the mark. The Product Owner needs to know what the teams need and how she can help them.
  • Product Owner<–>Customers
    The Product Owner and teams are trying to create the best possible product for the customer. The customer needs to know when they will have features they care about, and perhaps the reasoning behind the priorities. Involve them as much as possible by being transparent. The Product Owner needs to learn their real goals or problems with them (or envision something beyond their vision) and collect the information that will help him prioritize well.
  • Teams<–>Customers
    The teams are trying to create the best possible product for the customer. They need to know the context for features and have detailed domain knowledge. Ideally, teams co-create solutions directly with customers by grasping the customers’ essential (rather than superficial) goals and problems. Teams need to confirm with customers that they fully understand the requirements they are clarifying together.
  • Product Owner<–>Higher Management
    Higher management beyond the product group (portfolio managers, C-level executives, etc.) should view the Product Owner as having the final accountability and responsibility for product success. She is responsible for making the development status visible and realizing higher management’s (perhaps implicit) mandate to optimize desired impacts (e.g., ROI and market share). The Product Owner, with support from Scrum Masters, engages higher management’s help to improve the organizational design.
  • Product Owner<->Scrum Masters
    The relationships above are directly related to “product ownership,” but this one is different. It relates to Product Owner knowledge and behavior. The Scrum Masters need to know the Product Owner’s concerns, questions, and obstacles so they can help. A good Scrum Master can be a friendly ear or a shoulder to cry on. Scrum Masters educate and feed back so Product Owners can adapt.

LeSS Meetings

When we introduce LeSS, a frequent question is, “How is one Product Owner going to manage all of those meetings with all of those teams?” Fortunately, the concern behind that question is based on a misunderstanding. The one Product Owner in LeSS only attends single meetings even though there are multiple teams. And the number of team members at those single meetings is manageable. If there are just two teams, everyone can effectively attend and participate. If there are many teams, only two representatives from each team may attend.

What LeSS meetings does the Product Owner attend and what is their average duration in a typical two-week Sprint?

  • Sprint Planning One – 1 hour.
  • Overall Product Backlog Refinement (PBR) – 4 hours
  • Sprint Review – 2 hours.
  • Overall Retrospective – 1.5 hours.

So the total time spent in LeSS events is, on average, about eight hours in a two-week Sprint.

The Product Owner does not attend the team-specific meetings:

Sprint Planning Two, Daily Scrums, team PBRs, team Retrospectives.


Common Mistakes by Development Team

Members of the development team do not belong to the T-shaped group of people

The T-shaped model states that a person specializes in one specific field but has some general knowledge in other areas related to it as well. In other words – they know everything about something and something about everything. One of the key foundations of Scrum is the cross-functionality concept. Make sure that your teams consist of T-shaped people and help them improve their general knowledge by organising all sorts of internal workshops. If the development team, members are not willing to get out of their comfort zones and learn new things. It may be hard for them to work in a truly agile way. They will stick to the waterfall approach and focus on delivering “their” part of work, instead of taking the responsibility for the entire Sprint Backlog.

The team is too small

Small teams don’t have all the competences and skills necessary to deliver a releasable increment at the end of the Sprint which is the absolute foundation of the iterative development process. Finishing Sprints without delivering a fully functional items is not Scrum.

The team is too big

According to the Scrum Guide, the development team can consist of up to 9 members. If there are more people involved in the development process, communication problems may arise and it may be hard to maintain the Scrum events within the specified time frame.

Should be characteristics of a Product Owner

Visionary and Doer

The product owner is a visionary who can envision the final product and communicate the vision. But the product owner is also a doer who sees the vision through to completion. This includes capturing ideas and requirements, closely collaborating with the team, analyzing feedback from stakeholders and users, and steering the project by tracking and forecasting its progress. As an entrepreneur, the product owner facilitates creativity; encourages innovation; and is comfortable with change, ambiguity, debate, conflict, playfulness, experimentation, and informed risk taking.

Leader and Team Player

“Good business leaders create a vision, articulate the vision, passionately own the vision, and relentlessly drive it to completion,” says Jack Welch, GE’s former chairman and CEO. The product owner is just such a leader. As the individual responsible for the product’s success, the product owner provides guidance and direction for everyone involved in the development effort and ensures that tough decisions are made. For instance, should the launch date be postponed or should less functionality be delivered? At the same time, the product owner must be a team player who relies on close collaboration with the other Scrum team members, yet has no formal authority over them. You can think of the product owner as primus inter pares, first among peers, regarding the product.

Being a leader and team player can be a hard line to toe. By no means should the product owner dictate decisions, yet at the same time neither should the product owner be indecisive or employ a laissez-faire management style. Instead, the individual should act as a shepherd for the innovation process, guiding the project and seeking team consensus in the decision-making process. Making decisions about the product collaboratively ensures the team’s buy-in, leverages the team’s creativity and knowledge, and results in better decisions. Working this way requires facilitation and patience because team members often have to disagree and argue first before a new solution can be synthesized from the different ideas and perspectives.

Communicator and Negotiator

The product owner must be an effective communicator and negotiator. The individual communicates with and aligns different parties, including customers, users, development and engineering, marketing, sales, service, operations, and management. The product owner is the voice of the customer, communicating customer needs and requirements and bridging the gap between “the suits” and “the techies.” Sometimes this means saying no and other times negotiating a compromise.

Empowered and Committed

The product owner must have enough authority and the right level of management sponsorship to lead the development effort and to align stakeholders. An empowered product owner is essential for leading the effort to bring the product to life. The product owner must have the proper decision-making authority—from finding the right team members to deciding which functionality is delivered as part of the release. The individual must be someone who can be entrusted with a budget and at the same time has the ability to create a work environment that fosters creativity and innovation. Finally, the product owner must be committed to the development effort.

Available and Qualified

The product owner must be available and qualified to do a great job. Being the product owner is usually a full-time job. It is important to give product owners enough time to sustainably carry out their responsibilities. If the individual is overworked, the project’s progress suffers and the resulting product may be suboptimal. Being adequately qualified usually requires an intimate understanding of the customer and the market, being passionate about the user experience, and the ability to communicate needs and describe requirements, to manage a budget, to guide a development project, and to be comfortable working with a cross-functional, self-organizing team.

Nobody is Perfect

Before you now look for the perfect product owner or worry that you might not fit the bill, be aware that product owners usually need time and support to transition into the role and to acquire the necessary skills. And nobody is perfect: Every product owner has some strengths that facilitate playing the role as well as some weaknesses that can make it challenging. A product owner may be very good at envisioning the product, talking to customers, and creating the product roadmap but may not be used to work closely with a bunch of techies or lack the necessary release planning skills, for instance. A common challenge is finding employees with the necessary breadth and depth of knowledge and experience to do the job well.

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
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.


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.


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, 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: