Project Management Cheatsheet

Basic cheatsheets

• Initiation: Guiding questions and tips
• Planning: Guiding questions and tips
• Execution: Guiding questions and tips
• Closing: Guiding questions and tips

Source

At least 80% of this cheatsheet was inspired by Google Project Management on Coursera. I am not pretending to authority of these materials.

Comparing Waterfall and Agile Approaches

Key Distinction

Waterfall and Agile are implemented in many different ways on many different projects, and some projects may use aspects of each. The chart below briefly describes and compares Waterfall and Agile approaches. You can use it as a quick reference tool, but be aware that in practice, the differences between these two approaches may not always be clearly defined.

Waterfall vs Agile Comparison Table

Aspect	Waterfall	Agile
Project Manager’s Role	Project manager serves as an active leader by prioritizing and assigning tasks to team members	Scrum Master acts primarily as a facilitator, removing any barriers the team faces. Team shares more responsibility in managing their own work
Scope	Project deliverables and plans are well-established and documented in early stages. Changes go through formal change request process	Planning happens in shorter iterations and focuses on delivering value quickly. Subsequent iterations are adjusted based on feedback
Schedule	Follows a mostly linear path through initiating, planning, executing, and closing phases	Time is organized into Sprints. Each Sprint has defined duration with planned deliverables
Cost	Costs are controlled by careful upfront estimation and close monitoring throughout	Costs and schedule could change with each iteration
Quality	Project manager defines quality criteria and plans at project start	Team solicits ongoing stakeholder input and implements regular improvements
Communication	Project manager regularly communicates progress on milestones to stakeholders	Team maintains consistent communication between users and project team
Stakeholders	Project manager actively manages stakeholder engagement	Team frequently delivers to stakeholders and adjusts based on feedback

Lean and Six Sigma Methodologies

Lean Methodology

Definition

Lean methodology is often referred to as Lean Manufacturing because it originated in the manufacturing world. The main principle is removing waste within operations by optimizing processes and adding value at each production phase.

Eight Types of Waste in Lean

Today’s Lean Manufacturing recognizes eight types of operational waste:

1. Defects
2. Excess processing
3. Overproduction
4. Waiting
5. Inventory
6. Transportation
7. Motion
8. Non-utilized talent

Common Causes of Waste

Key Issues

In manufacturing, these wastes often stem from:

• Lack of proper documentation
• Missing process standards
• Poor understanding of customer needs
• Ineffective communication
• Insufficient process control
• Inefficient process design
• Management failures

Creating OKRs for your project

What are OKRs?

OKR stands for objectives and key results. They combine a goal and a metric to determine a measurable outcome. Objectives: Defines what needs to be achieved; describes a desired outcome. Key results: The measurable outcomes that objectively define when the objective has been met

Company-wide OKRs are used to set an ultimate goal for an entire organization, whole team, or department. Project-level OKRs describe the focused results each group will need to achieve in order to support the organization.

OKRs and project management

As a project manager, OKRs can help you expand upon project goals and further clarify the deliverables you’ll need from the project to accomplish those goals. Project-level OKRs help establish the appropriate scope for your team so that you can say “no” to requests that may get in the way of them meeting their objectives. You can also create and use project-level OKRs to help motivate your team since OKRs are intended to challenge you to push past what’s easily achievable.

Creating OKRs for your project

Set your objectives

Project objectives should be aspirational, aligned with organizational goals, action-oriented, concrete, and significant. Consider the vision you and your stakeholders have for your project and determine what you want the project team to accomplish in 3–6 months.

Examples:

• Build the most secure data security software

• Continuously improve web analytics and conversions

• Provide a top-performing service

• Make a universally-available app

• Increase market reach

• Achieve top sales among competitors in the region

Strong objectives meet the following criteria. They are:

• Aspirational

• Aligned with organizational goals

• Action-oriented

• Concrete

• Significant

To help shape each objective, ask yourself and your team:

• Does the objective help in achieving the project’s overall goals?

• Does the objective align with company and departmental OKRs?

• Is the objective inspiring and motivational?

• Will achieving the objective make a significant impact?

Develop key results

Next, add 2–3 key results for each objective. Key results should be time-bound. They can be used to indicate the amount of progress to achieve within a shorter period or to define whether you’ve met your objective at the end of the project. They should also challenge you and your team to stretch yourselves to achieve more.

Examples:

• X% new signups within first quarter post launch

• Increase advertiser spend by X% within the first two quarters of the year

• New feature adoption is at least X% by the end of the year

• Maximum 2 critical bugs are reported monthly by customers per Sprint

• Maintain newsletter unsubscribe rate at X% this calendar year

Strong key results meet the following criteria:

• Results-oriented—not a task

• Measurable and verifiable

• Specific and time-bound

• Aggressive yet realistic

To help shape your key results, ask yourself and your team the following:

• What does success mean?

• What metrics would prove that we’ve successfully achieved the objective?

OKR development best practices

Here are some best practices to keep in mind when writing OKRs:

• Think of your objectives as being motivational and inspiring and your key results as being tactical and specific. The objective describes what you want to do and the key results describe how you’ll know you did it.

• As a general rule, try to develop around 2–-3 key results for each objective.

• Be sure to document your OKRs and link to them in your project plan.

OKRs versus SMART goals

Earlier in this lesson, you learned how to craft SMART goals for your project. While SMART goals and OKRs have some similarities, there are key differences, as well. The following article describes how SMART goals and OKRs are similar, how they differ, and when you might want to use one or the other: Understanding the Unique Utility of OKRs vs. SMART Goals

To learn more how OKRs work to help project managers define and create measurable project goals and deliverables, check out the following resources:

• Google’s OKR playbook

• Planning company goals

• OKRs and SMART goals: What’s the difference?

• OKRs and KPIs: What They Are and How They Work Together

• How OKR and project management work together

• OKR Examples

• OKR TED Talk video (John Doerr, the founder of OKRs, explains why the secret to success is setting the right goals.)

Key Differences Between KPI and OKR

	KPI (Key Performance Indicator)	OKR (Objectives and Key Results)
What it is	A metric to measure performance	A goal-setting framework for achieving strategic aims
Purpose	Track efficiency and stability of operations	Drive focus, alignment, and growth
Structure	A number or percentage target	One Objective with 2–5 measurable Key Results
Ambition level	Targets are meant to be consistently achieved	Designed to be ambitious (70–80% completion is OK)
Review frequency	Ongoing, tracked weekly/monthly	Set quarterly or annually
Use case	Operational performance monitoring (e.g. sales, support)	Strategic alignment across teams and initiatives

How to Combine OKRs and KPIs Effectively

Step 1: Translate the CEO’s Directive into Company-Wide OKRs

Example CEO goal:

“Become the market leader and improve customer satisfaction.”

Company OKR Example:

Objective: Become the top-rated service in our industry

• KR1: Increase market share from 15% to 20%

• KR2: Raise CSAT to 92%

• KR3: Launch 2 new service features by Q4

Step 2: Cascade OKRs from Company → Departments → Teams → Individuals

Level	Type	Example Objective
Company	Strategic OKRs	”Become market leader in service”
Department	Tactical OKRs	”Enhance support efficiency”
Team	Team OKRs	”Automate ticket handling workflows”
Individual	Personal OKRs & KPIs	”Resolve 40+ tickets/day with CSAT ≥ 4.8”

Step 3: Link KPIs to OKRs for Performance Tracking

OKRs provide strategic direction, while KPIs measure performance execution.

OKR Key Result	Supporting KPI
Raise CSAT to 92%	Weekly customer satisfaction score
Reduce response time to 1 hour	Average ticket response time
Grow repeat purchases by 20%	Customer retention rate, LTV

Step 4: Use Tools and Dashboards for Visibility

• Use OKR tools (e.g., Weekdone, Perdoo, Gtmhub) for alignment.

• Track KPIs via BI dashboards, CRM tools, or Excel.

Step 5: Communicate Clearly and Engage Teams

• Host a company-wide OKR kickoff to explain top-level goals.

• Have managers guide teams in writing team- and individual-level OKRs.

• Align individual KPIs with OKR key results for consistency and accountability.

** In Summary:**

• OKRs = Focus, direction, ambition
• KPIs = Measurement, control, performance
• Together they ensure: strategic alignment + operational execution

Gathering information to define scope

Imagine that while working in a restaurant management group, your manager calls and asks you to “update the dining space,” then quickly hangs up the phone without providing further instruction. In this initial handoff from the manager, you are missing a lot of information. How do you even know what to ask?

Let’s quickly recap the concept of scope. The scope provides the boundaries for your project. You define the scope to help identify necessary resources, resource costs, and a schedule for the project.

In the situation we just described, here are some questions you might ask your manager in order to get the information you need to define the scope of the project:

Stakeholders

• How did you arrive at the decision to update the dining space?

• Did the request originate from the restaurant owner, customers, or other stakeholders?

• Who will approve the scope for the project?

Goals

• What is the reason for updating the dining space?

• What isn’t working in the current dining space?

• What is the end goal of this project?

Deliverables

• Which dining space is being updated?

• What exactly needs to be updated?

• Does the dining space need a remodel?

Resources

• What materials, equipment, and people will be needed?

• Will we need to hire contractors?

• Will we need to attain a floor plan and building permits?

Budget

• What is the budget for this project? Is it fixed or flexible?

Schedule

• How much time do we have to complete the project?

• When does the project need to be completed?

Flexibility

• How much flexibility is there?

• What is the highest priority: hitting the deadline, sticking to the budget, or making sure the result meets all the quality targets?

Strategies for controlling scope creep

The scope of a project can get out of control quickly—so quickly that you may not even notice it.

Warning

Scope creep is when a project’s work starts to grow beyond what was originally agreed upon during the initiation phase. Scope creep can put stress on you, your team, and your organization, and it can put your project at risk. The effects of scope creep can hinder every aspect of the project, from the schedule to the budget to the resources, and ultimately, its overall success.

Here are some best practices for scope management and controlling scope creep:

• Define your project’s requirements. Communicate with your stakeholders or customers to find out exactly what they want from the project and document those requirements during the initiation phase.

• Set a clear project schedule. Time and task management are essential for sticking to your project’s scope. Your schedule should outline all of your project’s requirements and the tasks that are necessary to achieve them.

• Determine what is out of scope. Make sure your stakeholders, customers, and project team understand when proposed changes are out of scope. Come to a clear agreement about the potential impacts to the project and document your agreement.

• Provide alternatives. Suggest alternative solutions to your customer or stakeholder. You can also help them consider how their proposed changes might create additional risks. Perform a cost-benefit analysis, if necessary.

• Set up a change control process. During the course of your project, some changes are inevitable. Determine the process for how each change will be defined, reviewed, and approved (or rejected) before you add it to your project plan. Make sure your project team is aware of this process.

• Learn how to say no. Sometimes you will have to say no to proposed changes. Saying no to a key stakeholder or customer can be uncomfortable, but it can be necessary to protect your project’s scope and its overall quality. If you are asked to take on additional tasks, explain how they will interfere with the budget, timeline, and/or resources defined in your initial project requirements.

• Collect costs for out-of-scope work. If out-of-scope work is required, be sure to document all costs incurred. That includes costs for work indirectly impacted by the increased scope. Be sure to indicate what the charges are for.

Triple Constraint

project managers may refer to the triple constraint model to manage scope and control scope creep. It can serve as a valuable tool to help you negotiate priorities and consider trade-offs.

For further reading on utilizing the triple constraint model in real-life scenarios as a project manager and how the triple constraint model has evolved over time, we recommend checking out this article: A Project Management Triple Constraint Example & Guide.

Essential project roles

The project manager

Although all team members are responsible for their individual parts of the project, the project manager is responsible for the overall success of the team, and ultimately, the project as a whole. A project manager understands that paying close attention to team dynamics is essential to successfully completing a project, and they use team-building techniques, motivation, influencing, decision-making, and coaching skills, to keep their teams strong.

Project managers integrate all project work by developing the project management plan, directing the work, documenting reports, controlling change, and monitoring quality.

In addition, project managers are responsible for balancing the scope, schedule, and cost of a project by managing engagement with stakeholders. When managing engagement with stakeholders, project managers rely on strong communication skills, political and cultural awareness, negotiation, trust-building, and conflict management skills.

Stakeholders

Have you ever heard the phrase “the stakes are high”? When we talk about “stakes,” we are referring to the important parts of a business, situation, or project that might be at risk if something goes wrong. To hold stake in a business, situation, or project means you are invested in its success. There will often be several parties that will hold stake in the outcome of a project. Each group’s level of investment will differ based on how the outcome of the project may impact them**.** Stakeholders are often divided into two groups: primary stakeholders, also known as key stakeholders, and secondary stakeholders. A primary stakeholder is directly affected by the outcome of the project, while a secondary stakeholder is indirectly affected by the outcome of the project.

Primary stakeholders usually include team members, senior leaders, and customers. For example, imagine that you are a project manager for a construction company that is commissioned to build out a new event space for a local catering company. On this project, the owners of the catering company would be primary stakeholders since they are paying for the project.

An example of a secondary stakeholder might be the project’s point of contact in legal. While the project outcome might not affect them directly, the project itself would impact their work when they process the contract. Each project will have a different set of stakeholders, which is why it’s important for the project manager to know who they are, what they need, and how to communicate with them.

Project team members

Every successful team needs strong leadership and membership, and project management is no exception! Project team members are also considered primary stakeholders, since they play a crucial role in getting the job done. Your team members will vary depending on the type, complexity, and size of the project. It’s important to consider these variables as you select your project team and begin to work with them. Remember that choosing teammates with the right technical skills and interpersonal skills will be valuable as you work to meet your project goals. If you are not able to select your project team, be sure to champion diversity and build trust to create harmony within the team.

Sponsor

The project sponsor is another primary stakeholder. A sponsor initiates the project and is responsible for presenting a business case for its existence, signing the project charter, and releasing resources to the project manager. The sponsor is very important to the project, so it’s critical to communicate with them frequently throughout all project phases. In our construction company example, the CEO could also be the project sponsor.

Prioritizing stakeholders and generating their buy-in

In this lesson, you are learning to complete a stakeholder analysis and explain its significance. Let’s focus here on how to prioritize the various types of stakeholders that can exist on a project, generate stakeholder buy-in, and manage their expectations.

Conducting a stakeholder analysis

Let’s review the key steps in the stakeholder analysis:

1. Make a list of all the stakeholders the project impacts. When generating this list, ask yourself: Who is invested in the project? Who is impacted by this project? Who contributes to this project?

2. Determine the level of interest and influence for each stakeholder—this step helps you determine who your key stakeholders are. The higher the level of interest and influence, the more important it will be to prioritize their needs throughout the project.

3. Assess stakeholders’ ability to participate and then find ways to involve them. Various types of projects will yield various types of stakeholders—some will be active stakeholders with more opinions and touchpoints and others will be passive stakeholders, preferring only high-level updates and not involved in the day-to-day. That said, just because a stakeholder does not participate as often as others does not mean they are not important. There are lots of factors that will play a role in determining a stakeholder’s ability to participate in a project, like physical distance from the project and their existing workload.

Visualizing your analysis

Quadrant 1: High Influence, High Interest (Upper Right)

Stakeholders in this quadrant have a significant influence on the project and are highly interested in its outcome. They can greatly impact project decisions and success. Examples might include project sponsors, key executives, or regulatory authorities. Responses for this quadrant include:

1. Engagement and Involvement:

   • Keep these stakeholders well-informed and engaged throughout the project lifecycle.

   • Involve them in decision-making processes, seeking their input and feedback.

   • Address their concerns promptly and effectively.

2. Regular Communication:

   • Schedule regular meetings or updates to keep them informed about project progress and any issues.

   • Tailor communication to their preferences and needs to ensure they remain supportive and engaged.

Quadrant 2: High Influence, Low Interest (Upper Left)

Stakeholders in this quadrant have high influence but may not be deeply interested in the day-to-day project details. They might include senior managers who need to be informed but may not be actively engaged. Responses for this quadrant include:

1. Executive Summaries:

   • Provide high-level summaries of project progress and key decisions for their review.

   • Focus on the impact of the project on organizational goals and objectives.

2. Periodic Updates:

   • Provide periodic briefings or updates to ensure they are informed of major milestones and critical project changes.

Quadrant 3: Low Influence, High Interest (Bottom Right)

Stakeholders in this quadrant have a high interest in the project but relatively low influence on its outcome. They are typically looking for updates and information about the project. Responses for this quadrant include:

1. Regular Updates:

   • Communicate project progress, risks, and updates to keep them engaged and informed.

   • Address their queries and concerns promptly to maintain their interest.

2. Stakeholder Feedback:

   • Seek their feedback on project plans, progress, and outcomes to ensure their perspective is considered.

Quadrant 4: Low Influence, Low Interest (Bottom Left)

Stakeholders in this quadrant have low influence on the project and limited interest in its details. They might include lower-level employees or departments not directly impacted by the project. Responses for this quadrant include:

1. General Communication:

   • Share general updates about the project’s overall progress without overwhelming them with details.

   • Address any specific questions they may have, but avoid unnecessary inundation with project-related information.

2. Minimal Engagement:

   • Maintain a basic level of communication and engagement to keep them aware of the project without distracting them from their regular responsibilities.

Project charters: Elements and formats

A project charter clearly defines the project and outlines the necessary details for the project to reach its goals. A well-documented project charter can be a project manager’s secret weapon to success. In this reading, we will go over the function, key elements, and significance of a project charter and learn how to create one.

Project charters will vary but usually include some combination of the following key information:

• introduction/project summary
• goals/objectives
• business case/benefits and costs
• project team
• scope
• success criteria
• major requirements or key deliverables
• budget
• schedule/timeline or milestones
• constraints and assumptions
• risks
• OKRs
• approvals

Example of a project charter

Setting milestones: Best practices

Set tasks to identify milestones

Setting tasks can help you clearly define milestones. You can do this in two ways:

1. Top-down scheduling: In this approach, the project manager lays out the higher-level milestones, then works to break down the effort into project tasks. The project manager works with their team to ensure that all tasks are captured.

2. Bottom-up scheduling: In this approach, the project manager looks at all of the individual tasks that need to be completed and then rolls those tasks into manageable chunks that lead to a milestone.

Milestone-setting pitfalls

Here are some things to avoid when setting milestones:

• Don’t set too many milestones. When there are too many milestones, their importance is downplayed. And, if milestones are too small or too specific, you may end up with too many, making the project look much bigger than it really is to your team and stakeholders.

• Don’t mistake tasks for milestones. Remember that milestones should represent moments in time, and in order to map out how you will get to those moments, you need to assign smaller tasks to each milestone.

• Don’t list your milestones and tasks separately. Make sure that tasks and milestones can be visualized together in one place, such as a project plan. This will help ensure that you are hitting your deadlines and milestones.

Breaking down the work breakdown structure

WBS is a deliverable-oriented breakdown of a project into smaller components. It’s a tool that sorts the milestones and tasks of a project into a hierarchy, in the order they need to be completed.

A thorough WBS gives you a visual representation of a project and the tasks required to deliver each milestone. It makes it easier to understand all of the essential project tasks, such as estimating costs, developing a schedule, assigning roles and responsibilities, and tracking progress. Think of each piece of information as part of the overall project puzzle—you can’t successfully navigate through the tasks without understanding how they all fit together. For instance, many smaller tasks may ladder up to a larger task or milestone.

Steps to build a WBS

As a reminder, here are three main steps to follow when creating a WBS:

• Start with the high-level, overarching project picture. Brainstorm with your team to list the major deliverables and milestones. Example: Imagine you are planning a company event. Your major milestones might include categories like “secure venue,” “finalize guest logistics,” and “establish agenda.”

• Identify the tasks that need to be performed in order to meet those milestones. Example: You could break a milestone like “secure venue” down into tasks like “research venues,” “tour and decorate space,” “make down payment,” and so on.

• Examine those tasks and break them down further into sub-tasks. Example: You could break down a task like “tour and decorate space” further into sub-tasks like “organize decorating committee,” “purchase decorations,” “assign decorating responsibilities,” and so on.

Further reading

For further learning on best practices for developing a WBS, check out this article:

• How to Create a Work Breakdown Structure and Why You Should

Overcoming the planning fallacy

It is human nature to underestimate the amount of time and effort it takes to complete a task—from anything as simple as walking the dog to something as complex as completing a project. People generally want to remain hopeful about a positive outcome, and this is a great quality to have as a person. But as a project manager, this kind of optimism can also be a deficiency, especially during the planning phase of a project. Let’s examine a theory known as the planning fallacy to better understand how to set yourself up for success in the planning phase.

The planning fallacy and optimism bias

The idea of the planning fallacy was first introduced in a 1977 paper written by Daniel Kahneman and Amos Tversky, two foundational figures in the field of behavioral economics. The planning fallacy describes our tendency to underestimate the amount of time it will take to complete a task, as well as the costs and risks associated with that task, due to optimism bias. Optimism bias is when a person believes that they are less likely to experience a negative event. For example, when you are planning to walk your dog in between meetings, you might think that you can do it faster than you actually can. Optimism bias is what tells you that you are going to be able to walk your dog without being late for your next meeting. If you don’t consider things that might affect the time it will take you to walk your dog—the weather, the chance of them running into another dog and wanting to play, or the fact that they frequently get distracted while sniffing around—you might be late for your next meeting, or you might miss it altogether!

Avoiding the planning fallacy: A case study

Think about the planning fallacy in relation to yourself as a project manager. If you have planned massive efforts in your project plan with an optimism bias, this planning fallacy could have a major impact on your project execution. You could set your team up for failure by not giving them enough time to complete their tasks, causing work to have to be redone or missing opportunities to execute the project more efficiently.

Let’s examine how this happens. David is a project manager responsible for a home construction project. Let’s check out his Work Breakdown Structure (WBS):

Working through his plan, David knows that certain things need to happen for the house to be completed. He has to order materials, the materials have to be delivered, the contractor has to actually build the house, and there needs to be time for completing finishing touches and adjustments. The time estimations for those major tasks might break down like this:

Task	Estimated Duration
Foundation	2 weeks
Construction	4 weeks
Adjustments	4 weeks

After creating a WBS and a time estimation chart, David estimates that the construction project will take a total of ten weeks. This sounds perfect because it meets his delivery requirement. If David is unaware of the planning fallacy, he may think his plan is solid and that his team is on their way to building the house within the target timeline!

Fortunately, David is mindful of the planning fallacy. He examines the time estimates more carefully. He considers risks like weather delays or crew members calling out sick, which could set the project’s completion date back. He meets with his team members and other stakeholders to help him uncover other possible risks that could affect the project timeline. After carefully gathering information, he adjusts the time estimates, adding task buffers to some of the project tasks to account for the potential risks.

Creating a critical path

The critical path helps you determine the essential tasks that need to be completed on your project to meet your end goal and how long each task will take. The critical path also provides a quick reference for critical tasks by revealing which tasks will impact your project completion date negatively if their scheduled finish dates are late or missed. A critical path can help you define the resources you need, your project baselines, and any flexibility you have in the schedule.

How to create a critical path

Step 1: Capture all tasks

The main goal in this step is to make sure that you aren’t missing a key piece of work that is required to complete your project. When creating a critical path, focus on the essential, “need to do” tasks, rather than the “nice to do” tasks that aren’t essential for the completion of the project. Here is an example of critical tasks for building the structure of a house:

Task
A) Excavation
B) Foundation
C) Framing
D) Roof
E) Plumbing
F) Heating, ventilation, and air conditioning (HVAC)
G) Electrical
H) Insulation
I) Drywall + Paint
J) Flooring

Step 2: Set dependencies

To figure out dependencies for each task, ask:

• Which task needs to take place before this task?

• Which task can be finished at the same time as this task?

• Which task needs to happen right after this task?

Once you have answered these questions, you can list these dependencies next to your list of tasks:

Task	Dependency
A) Excavation
B) Foundation	A) Excavation
C) Framing	B) Foundation
D) Roof	C) Framing
E) Plumbing	C) Framing
F) HVAC	C) Framing
G) Electrical	C) Framing
H) Insulation	E) Plumbing, F) HVAC, G) Electrical
I) Drywall + Paint	H) Insulation
J) Flooring	I) Drywall + Paint

Step 3: Create a network diagram

One common way to visualize the critical path is by creating a network diagram. Network diagrams, like the example below, sequence tasks in the order in which they need to be completed, based on their dependencies. These diagrams help visualize:

• The path of the work from the start of the project (excavation) to the end of the project (flooring)

• Which tasks can be performed in parallel (e.g., HVAC and plumbing) and in sequence (e.g., plumbing then insulation)

• Which non-essential tasks are NOT on the critical path

(Long description of graphic above: Essential tasks, including Start, Excavation, Foundation, Framing, Roof, HVAC, Plumbing, Electrical, Insulation, Drywall+Paint, Flooring, and Finish, are laid out in a sequential path and highlighted in blue. Roof, HVAC, and Electrical are shown as tasks able to be done concurrently with Framing and Plumbing. Non-essential tasks are separated from essential tasks and are highlighted in red. Non-essential tasks include Driveway Pavement, Landscaping, Trim, and Appliances.)

Step 4: Make time estimates

After determining tasks and dependencies, consult key stakeholders to get accurate time estimates for each task. This is a crucial step in determining your critical path. If your time estimates are significantly off, it may cause the length of your critical path to change. Time estimates can be reviewed and updated throughout the project, as necessary.

Task	Duration	Dependency
A) Excavation	1 Day
B) Foundation	3 Days	A) Excavation
C) Framing	15 Days	B) Foundation
D) Roof	3 Days	C) Framing
E) Plumbing	4 Days	C) Framing
F) HVAC	3 Days	C) Framing
G) Electrical	3 Days	C) Framing
H) Insulation	2 Days	E) Plumbing, F) HVAC, G) Electrical
I) Drywall + Paint	15 Days	H) Insulation
J) Flooring	7 Days	I) Drywall + Paint

Step 5: Find the critical path

If you add up the durations for all of your “essential” tasks and calculate the longest possible path, you can determine your critical path. In your calculation, only include the tasks that, if they go unfinished, will impact the project’s finish date. In this example, if the “non-essential” tasks—like landscaping and driveway pavement—are not completed, the house structure completion date will not be impacted.

You can also calculate the critical path using two common approaches: the forward pass and the backward pass. These techniques are useful if you are asked to identify the earliest and latest start dates (the earliest and latest dates on which you can begin working on a task) or the slack (the amount of time that task can be delayed past its earliest start date without delaying the project).

• The forward pass refers to when you start at the beginning of your project task list and add up the duration of the tasks on the critical path to the end of your project. When using this approach, start with the first task you have identified that needs to be completed before anything else can start.
• The backward pass is the opposite—start with the final task or milestone and move backwards through your schedule to determine the shortest path to completion. When there is a hard deadline, working backwards can help you determine which tasks are actually critical. You may be able to cut some tasks—or complete them later—in order to meet your deadline.

You can read more about each of these concepts and critical path calculation methods in the following articles:

• How to Use the Critical Path Method for Complete Beginners

• Critical Path Method: A Project Management Essential

Project budgeting best practices

Here are a few tips to consider when creating your project budget:

• Reference historical data: Your project may be similar to a previous project your organization has worked on. It is important to review how that project’s budget was handled, find out what went well, and learn from any previous mistakes.

• Utilize your team, mentors, or manager: Get into the habit of asking for your team to double check your work to give you additional sets of eyes on your documents.

• Time-phase your budget: Time-phased budgeting allows you to allocate costs for project tasks over the projected timeline in which those expenses are planned to take place. By looking at your tasks against a timeline, you can track and compare planned versus actual costs over time and manage changes to your budget as necessary.

• Check, check, and double check: Make sure that your budget is accurate and error-free. Your budget will likely require approval from another department, such as finance or senior management, so do your best to ensure that it is as straightforward to understand as possible and that all of your calculations are correct.

Categorize different types of costs

There are different types of costs that your project will incur. For example, you may need to account for both direct costs and indirect costs in your project budget. Categorize these different types of costs in your budget so that you can ensure you are meeting the requirements of your organization and customer.

Direct costs

These are costs for items that are necessary in order to complete your project. These costs can include:

• Wages and salaries of employees and contractors

• Materials costs

• Equipment rental costs

• Software licenses

• Project-related travel and transportation costs

• Staff training

Indirect costs

These are costs for items which do not directly lead to the completion of your project but are still essential for the project team to do their work. They are also referred to as overhead costs. These costs can include:

• Administrative costs

• Utilities

• Insurance

• General office equipment

• Security

Develop a baseline budget

A baseline budget is an estimate of project costs that you start with at the beginning of your project. Once you have created a budget for your project and gotten it approved, you should publish this baseline and use it to compare against actual performance progress. This will give you insight into how your project budget is doing and allow you to make informed adjustments.

It is important to continually monitor your project budget and make changes if necessary. Be aware that budget updates can require the same approvals as your initial budget. Also, you should “re-baseline” your budget if you make significant changes. Re-baselining refers to when you update or modify a project’s baseline as a result of any approved change to the schedule, cost, or deliverable content. For example, if you have a significant change in your project scope, your budget will likely be impacted. In this instance, you would need to re-baseline in order to adhere to a realistic budget.

Perform a reserve analysis

A reserve analysis will help you account for any buffer funds you may need. First, review all potential risks to your project and determine if you need to add buffer funds, also referred to as a contingency budget. These funds are necessary because new costs that you did not expect are likely to happen throughout the project. You may also want to account for cost of quality in your overall project budget. The cost of quality refers to all of the costs that are incurred to deliver a quality product or service, which can extend beyond material resources. This includes addressing issues with products, processes, or tasks, along with internal and external failure costs. One example would be having to redesign a product or service due to defects. A defect could mean refunds to customers, time and money required to create a new product or service, and multiple other potential costs affecting the client.

Helpful budget templates

Budget templates are a useful tool for helping you estimate, track, and maintain a project budget. Below, you will find a few different budget templates that you can use for future projects. Each of these templates is formatted in a digital spreadsheet.

Microsoft Excel Budget Templates

Microsoft Excel Website Budget Template (applicable to any project)

Google Sheets Budget Template (Note: You will need to be signed in to a Google account in order to make a copy of the template.)

Overcoming budgeting challenges

Challenge 1: Budget pre-allocation

You may encounter situations where your budget is already set before you even start the project. This is known as budget pre-allocation. Some organizations follow strict budgeting cycles, which can lead to cost estimations taking place before the scope of the project is completely defined.

If you are given a pre-allocated budget, it is important to work with your customer to set expectations on scope and deliverables within the allocated budget. To deliver a great product within your allocated budget will require detailed planning.

A pre-allocated budget should also be routinely monitored to ensure the amounts you have budgeted are sufficient to meet your costs. Be sure to carefully track all expenses in your budget. Regularly match these expenses against your pre-allocated budget to ensure you have sufficient funds for the remainder of your project.

Part of that planning includes making sure that you are tracking fixed and time- and materials-based expenses. Fixed contracts are usually paid for when certain milestones are reached. Time and materials contracts are usually paid for monthly, based on the hours worked and other fees associated with the work, such as travel and meal expenses.

Challenge 2: Inaccurately calculating TCO

Another budgeting pitfall you should try to avoid is underestimating the total cost of ownership (TCO) for project resources. TCO takes into account multiple elements that contribute to the cost of an item. It factors in the expenses associated with a product or service over its lifetime, rather than just upfront costs.

Let’s relate TCO to something more common, like owning a vehicle. Let’s say you buy a vehicle for a certain price, but then you also pay for things related to the vehicle, such as license fees, registration fees, and maintenance. If you add all of this up, you have your TCO for that vehicle. So now that you know what your TCO is, you may consider those fees before you buy your next vehicle. For example, you might opt for a vehicle with fewer maintenance requirements than one that requires more frequent service, since you know that will save you money overall.

The same concept applies to budgeting on a project. If you have a service requirement for a software technology that your team is using, for example, then it is important to budget for the costs of maintenance for that service. Additional types of costs you may need to account for when calculating TCO include warranties, supplies, required add-on costs, and upgrade costs.

Challenge 3: Scope creep

Scope creep is when changes, growth, and other factors affect the project’s scope at any point after the project begins. Scope creep causes additional work that wasn’t planned for, so scope creep can also impact your budget.

There are several factors that can lead to scope creep, such as:

• A vague Statement of Work (SoW)

• Conversations and agreements about the project that aren’t officially documented

• Unattainable timeframes and deadlines

• Last-minute asks from priority stakeholders

Addressing these factors as you plan your project can help prevent scope creep from impacting your budget.

Introduction to budgeting terms

Cash flow

Cash flow is the inflow and outflow of cash on your project. As a project manager, this is important to understand because you need funding (cash into your project) to keep your project running.

Cash that comes into your project allows you to maintain and compensate resources and pay invoices for materials or outside services. In some cases, a project may start out with all of the cash it will receive until the end. If this is the case, it is important to monitor your outflow to ensure that you have enough funding to complete the project.

Monitoring cash flow allows you to have a reference point for your project’s health. For example, if the cash flow coming into your project is lower than your outflow, you will need to adjust your budget. Planning and tracking the cash flow for your project is a key component of budget management.

CAPEX and OPEX

Organizations have a number of different types of expenses, from the wages they pay their employees to the cost of materials for their products. These expenses can be organized into different categories. Two of the most common are CAPEX (capital expenses) and OPEX (operating expenses).

• CAPEX (capital expenses) are an organization’s major, long-term, upfront expenses, such as buildings, equipment, and vehicles. They are generally for assets that the company will own and keep. The company incurs these expenses because they believe they will create a benefit for the company in the future.

• OPEX (operating expenses) are the short-term expenses that are required for the day-to-day tasks involved in running the company, such as wages, rent, and utilities. They are often recurring.

You may need to account for both OPEX and CAPEX on your projects. For example, a major software acquisition as part of an IT project could be treated by your organization as a capital expense. The monthly wages paid to a contractor to help deploy the software would be an operating expense. It’s a good idea to talk to your finance or accounting department when you start working on your project budget to see how they determine the difference between OPEX and CAPEX. This will guide you in properly allocating capital and operating expenses for your projects.

Contingency reserves

Sometimes, a project hits a snag and incurs additional expenses. One way to prepare for unplanned costs is by using contingency reserves. Contingency reserves are funds added to the estimated project cost to cover identified risks. These are also referred to as buffers.

To determine the amount of your contingency reserves, you will need to go through the risk management process and identify the risks that are most likely to occur. We will go into more detail on risk management later in the course, but it is important to understand that risks to your project can have an impact on your budget.

Contingency reserves can also be used to cover areas where actual costs turn out to be higher than estimated costs. For example, you may estimate a certain amount for labor costs, but if a contracted worker on your team gets a raise, then the actual costs will be higher than you estimated.

Management reserves

While contingency reserves are used to cover the costs of identified risks, management reserves are used to cover the costs of unidentified risks. For example, if you were managing a construction project and a meteor hit your machinery, you could use management reserves to cover the costs of the damage.

Contingency reserves are an estimated amount, whereas management reserves are generally a percentage of the total cost of the project. To determine a project’s management reserves, you can estimate a percentage of the budget to set aside. This estimate is typically between 5–10%, but the amount is based on the complexity of the project. A project with a more complex scope may require higher management reserves. Note that the project manager will generally need approval from the project sponsor in order to use management reserves.

Phases of risk management

1. Identify the risk. The first phase of the risk management process is to identify and define potential project risks with your team. After all, you can only manage risks if you know what they are.

2. Analyze the risk. After identifying the risks, determine their likelihood and potential impact to your project. Serious risks with a high probability of occurring pose the greatest threat.

3. Evaluate the risk. Next, use the results of your risk analysis to determine which risks to prioritize.

4. Treat the risk. During this phase, make a plan for how to treat and manage each risk. You might choose to ignore minor risks, but serious risks need detailed mitigation plans.

5. Monitor and control the risk. Finally, assign team members to monitor, track, and mitigate risks if the need arises.

Four types of Risk mitigation

Let’s imagine that Office Green uses plant seeds from a company in South America for the majority of its offerings. The plants produced by these seeds are in high demand by Office Green’s customers. However, the local government on the suppliers’ end just announced that it would be imposing a new tax on the exporting of seeds and produce. As a result, the price of the seeds suddenly becomes so high that it is difficult for the company to supply the seeds to Office Green, putting the project at risk of not having these seeds available to purchase.

Avoid

This strategy seeks to sidestep—or avoid—the situation as a whole. In the Office Green example, the team could avoid this risk entirely by considering using another seed that is widely available in several locations.

Minimize

Mitigating a risk involves trying to minimize the catastrophic effects that it could have on the project. The key to minimizing risk starts with realizing that the risk exists. That is why you will usually hear mitigation strategies referred to as workarounds. What if the Office Green team decided to use both the original South American supplier and another supplier from a neighboring country? More than likely, the change in taxation and regulation wouldn’t affect both companies, and this would provide Office Green some flexibility without having to completely eliminate their preferred supplier.

Transfer

The strategy of transferring shifts the responsibility of handling the risk to someone else. The Office Green team could find a supplier in North America that uses the seeds from several other South American countries and purchase the seeds from them instead. This transfers the ownership of South American regulatory risks and costs to that supplier.

Accept

Lastly, you can accept the risk as the normal cost of doing business. Active acceptance of risk usually means setting aside extra funds to pay your way out of trouble. Passive acceptance of risk is the “do nothing” approach. While passive acceptance may be reasonable for smaller risks, it is not recommended for most single point of failure risks. It is also important to be proactive and mitigate risks ahead of time whenever possible, as this may save you from having to accept risks. In the Office Green scenario, the project manager could schedule a meeting with project stakeholders to discuss the increase in South American taxes and how it could impact the project cost. Then, they might decide to actively accept the risk by setting aside additional funds to source the seeds from another supplier, if necessary, or to passively accept the risk of not receiving the seeds at all this season.

Visualizing dependency relationships

In the video, you learned to identify several types of risks. In this reading, we will be discussing the different types of dependencies that can play a critical role in our project’s success.

Types of dependencies

Dependencies are a relationship between two project tasks in which the completion or the initiation of one is reliant on the completion or initiation of the other. Let’s explore four common types of dependencies:

Finish to Start (FS)

In this type of relationship between two tasks, Task A must be completed before Task B can start. This is the most common dependency in project management. It follows the natural progression from one task to another.

Example: Imagine you are getting ready to have some friends over for dinner. You can’t start putting on your shoes (Task B) until you’ve finished putting on your socks (Task A).

Task A: Finish putting on your socks. →Task B: Start putting on your shoes.

Finish to Finish (FF)

In this model, Task A must finish before Task B can finish. (This type of dependency is not common.)

Example: Earlier in the day, you baked a cake. You can’t finish decorating the cake (Task B) until you finish making the icing (Task A).

Task A: Finish making the icing. →Task B: Finish decorating the cake.

Start to Start (SS)

In this model, Task B can’t begin until Task A begins. This means Tasks A and B start at the same time and run in parallel.

Example: You need to take the train home after work. You can’t get on the train (Task B) until you pay for the train ride (Task A).

Task A: Start by paying for your train ride. →Task B: Start going home by boarding the train.

Start to Finish (SF)

In this model, Task A must begin before Task B can be completed.

Example: One of your friends calls to tell you he’ll be late. He can’t finish his shift (Task B) and leave work until his coworker arrives to start her shift (Task A).

Task A: Your friend’s coworker starts her shift. →Task B: Your friend finishes his shift.

Writing an effective escalation email

All projects—even those managed by experienced project managers—occasionally have problems. Your role as the project manager is to help resolve problems and remove barriers that prevent your team from making progress toward your goals. While many problems might be small enough to resolve within your core team, other problems—like a major change in your budget or timeline—may need to be brought to stakeholders for a final decision. Detailing these problems, their potential impact, and the support you need in a clear and direct email to your audience can be an effective communication tool.

Effective escalation emails:

• Maintain a friendly tone

• State your connection to the project

• Explain the problem

• Explain the consequences

• Make a request

Let’s discuss these five keys to writing a strong escalation email.

Maintain a friendly tone

When drafting an escalation email, you may feel tempted to get straight to the point, especially when dealing with a stressful and time-sensitive problem. But keep in mind that it is important to address issues with grace. Consider opening your email with a simple show of goodwill, such as “I hope you’re doing well.” When describing the issue, aim for a blameless tone. Above all, keep the email friendly and professional. After all, you are asking for the recipient’s help. Be sure to close your email by thanking the recipient for their time.

State your connection to the project

Introduce yourself early in the email if you have less familiarity with the project stakeholders. Be sure to clearly state your name, role, and relationship to the project. This helps the reader understand why you are reaching out. Keep your introduction brief and to the point—a single sentence should suffice. If you know the person on the receiving end of the escalation email, you can simply reinforce your responsibility on the project before getting straight to the problem.

Explain the problem

Once you greet your recipient and briefly introduce yourself, explain the issue at hand. Clearly state the problem you need to solve. Provide enough context for the reader to understand the issue, but aim to keep your message as concise as possible. Avoid long, dense paragraphs that may obscure your message and tempt the reader to skim.

Explain the consequences

After explaining the problem, clearly outline the consequences. Describe specifically how this issue is negatively impacting the project or how it has the potential to negatively impact the project later in the project timeline. Again, keep your explanation concise and your tone friendly.

Propose a course of action and make a request

This is the central piece of a strong escalation email. In this section, you propose a solution (or solutions) and state what you need from the recipient. A thoughtful solution accompanied by a clear request lets the recipient know how they can help and moves you toward a resolution.

Putting it all together

Let’s see how these best practices come together to form a strong escalation email. In the scenario that prompts the email, Sayid, a project manager from a company that sells gift baskets, is having a quality control issue with one of the items in a line of holiday baskets. If the issue is not rectified soon, the product launch will have to be delayed and the company will lose money. In the annotated email example below, Sayid explains the issue to his internal stakeholders and requests a meeting with them.

Alternate text of email:

To: knelson@graciousgiftbaskets.com, gabrielmendoza@graciousgiftbaskets.com [Your stakeholders]

Subject: [Action required] Decision needed to make progress on Holiday Scents project

Hi Karen and Gabriel,

[Keep it friendly and state your connection to the project] I hope you are doing well. As you may know, I have been managing our Holiday Scents product line, which is scheduled to launch in October.

[Explain the problem] I would like to bring an issue to your attention. The baskets in this product line will include scented candles, and we placed an order with Candlemakers, Inc. for 5,000 candles to be delivered to the warehouse by Friday to prepare for our first customer shipment. To date, we have received 3,000 of the 5,000 candles. Unfortunately, many of the candles we have received so far fail to meet our quality standards. The packaging is damaged, or the candles themselves are broken.

[Explain the consequences] This puts our customer satisfaction rates at risk. Failure to meet the quality requirements for the candles by Friday will result in postponing the product launch by three weeks. If this delay occurs, we will incur an additional cost of $20,000 because we will need to order a new shipment of candles and review the quality standards of each to ensure that they meet our contractual agreements.

[Propose a course of action and make a request] I have sourced two backup suppliers that have five-star reviews and a track record of on-time deliveries. I propose we meet with them both right away so we can onboard one of them quickly. That way, we can avoid major delays. Are you available for a meeting tomorrow to discuss options and come to an agreement on next steps? Please respond with the times that work best for you.

Thank you in advance for your consideration and insight,

Sayid

End of email

What Is DMAIC?

DMAIC is a data-driven improvement cycle used to enhance, stabilize, and optimize business processes. It serves as the core tool for driving Six Sigma projects.

The Five Phases of DMAIC

1. Define

   • Identify the problem and improvement needs
   • Set clear, specific goals
   • Document project scope and boundaries
   • Establish stakeholder requirements

2. Measure

   • Quantify the identified issues
   • Gather baseline performance data
   • Validate measurement systems
   • Determine current process capability

3. Analyze

   • Determine root causes
   • Identify key process variables
   • Validate cause-and-effect relationships
   • Prioritize improvement opportunities

4. Improve

   • Develop potential solutions
   • Test and validate improvements
   • Implement change management
   • Document new procedures

5. Control

   • Monitor implemented changes
   • Ensure sustained improvements
   • Standardize successful changes
   • Document lessons learned

What Is PDCA?

PDCA is a four-stage model (Plan, Do, Check, Act) designed for continuous improvement in business process management, introduced by Dr. Edward Deming in 1950.

The PDCA cycle forms the foundation of Total Quality Management (TQM) and ISO 9001 quality standards and is widely used in areas such as production management, supply chain management, project management, and human resource management. Here is an overview of each stage:

• Plan: This initial phase involves decision-makers analyzing current inefficiencies and identifying the need for change. Key questions include the best methods for implementing change and assessing the associated costs and benefits.
• Do: This stage focuses on executing the planned improvements. Clear communication with affected employees is essential to ensure understanding and support for the changes. If resistance arises, decision-makers should be prepared to address it with appropriate measures.
• Check: In the Check stage, decision-makers assess whether the desired outcomes were achieved by comparing actual results with the expected results.
• Act: Actions in this stage depend on the findings from the Check stage. If the evaluation shows that the improvements were successful, the new processes should be standardized and maintained.

Quality management concepts

• Quality standards provide requirements, specifications, or guidelines that can be used to ensure that products, processes, or services are fit for achieving the desired outcome. These standards must be met in order for the product, process, or service to be considered successful by the organization and the customer. You will set quality standards with your team and your customer at the beginning of your project. Well-defined standards lead to less rework and schedule delays throughout your project.

• Quality planning involves the actions of you or your team to establish and conduct a process for identifying and determining exactly which standards of quality are relevant to the project as a whole and how to satisfy them. During this process, you’ll plan the procedures to achieve the quality standards for your project.

• Quality assurance, or QA, is a review process that evaluates whether the project is moving toward delivering a high-quality service or product. It includes regular audits to confirm that everything is going to plan and that the necessary procedures are being followed. Quality assurance helps you make sure that you and your customers are getting the exact product you contracted for.

• Quality control, or QC, involves monitoring project results and delivery to determine if they are meeting desired results. It includes the techniques that are used to ensure quality standards are maintained when a problem is identified. Quality control is a subset of quality assurance activities. While QA seeks to prevent defects before they occur, QC aims to identify defects after they have happened and also entails taking corrective action to resolve these issues.

The goals of UAT

Important

UAT is testing that helps a business make sure that a product, service, or process works for its users. The main objectives of UAT are to:

• Demonstrate that the product, service, or process is behaving in expected ways in real-world scenarios.
• Show that the product, service, or process is working as intended.
• Identify issues that need to be addressed before project completion.

Best practices for effective UAT

In order to achieve these goals, UAT needs to be conducted thoughtfully. These best practices can help you administer effective UAT:

• Define and write down your acceptance criteria. Acceptance criteria are pre-established standards or requirements that a product, service, or process must meet. Write down these requirements for each item that you intend to test. For example, if your project is to create a new employee handbook for your small business, you may set acceptance criteria that the handbook must be a digital PDF that is accessible on mobile devices and desktop.

• Create the test cases for each item that you are testing. A test case is a sequence of steps and its expected results. It usually consists of a series of actions that the user can perform to find out if the product, service, or process behaved the way it was supposed to. Continuing with the employee handbook example, you could create a test case process in which the user would click to download the PDF of the handbook on their mobile device or desktop to ensure that they could access it without issues.

• Select your users carefully. It is important to choose users who will actually be the end users of the product, service, or process.

• Write the UAT scripts based on user stories. These scripts will be delivered to the users during the testing process. A user story is an informal, general explanation of a feature written from the perspective of the end user. In our employee handbook example, a user story might be: As a new employee, I want to be able to use the handbook to easily locate the vacation policy and share it with my team via email.

• Communicate with users and let them know what to expect. If you can prepare users ahead of time, there will be fewer questions, issues, or delays during the testing process.

• Prepare the testing environment for UAT. Ensure that the users have proper credentials and access, and try out these credentials ahead of time to ensure they work.

• Provide a step-by-step plan to help guide users through the testing process. It will be helpful for users to have some clear, easy-to-follow instructions that will help focus their attention on the right places. You can create this plan in a digital document or spreadsheet and share with them ahead of time.

• Compile notes in a single document and record any issues that are discovered. You can create a digital spreadsheet or document that corresponds to your plan. It can have designated areas to track issues for each item that is tested, including the users’ opinions on the severity of each issue. This will help you prioritize fixes.

Managing UAT feedback

Users provide feedback after performing UAT. This feedback might include positive comments, bug reports, and change requests. As the project manager, you can address the different types of feedback as follows:

• Bugs or issues: Users might report technical issues, also known as bugs, or other types of issues after performing UAT. You can track and monitor these issues in a spreadsheet or equivalent system and prioritize which issues to fix. For instance, critical issues, such as not being able to access, download, or search the employee handbook, need to be prioritized over non-critical issues, such as feedback on the cover art of the handbook.

• Change requests: Sometimes the user might suggest minor changes to the product, service, or process after UAT. These types of requests or changes should also be managed and prioritized. Depending on the type and volume of the requests, you may want to share this data with your primary stakeholders, and you may also need to adjust your project timeline to implement these new requests.

Managing UAT Feedback

Types of Feedback

Users provide different types of feedback after performing UAT, including:

• Positive comments
• Bug reports
• Change requests

Addressing Different Types of Feedback

Bugs and Issues

Critical vs Non-Critical

Users might report technical issues (bugs) or other types of issues after UAT. Track and prioritize these issues based on severity:

• Critical issues (high priority): Problems that prevent core functionality (e.g., inability to access or download)
• Non-critical issues (lower priority): Cosmetic or minor concerns (e.g., feedback on visual elements)

Tracking Process:

1. Create a dedicated spreadsheet or tracking system
2. Document all reported issues
3. Assess severity of each issue
4. Prioritize fixes based on impact
5. Monitor resolution progress

Change Requests

Managing Changes

Users may suggest modifications to the product, service, or process after UAT. Handle these requests by:

1. Documenting all requested changes
2. Evaluating impact and feasibility
3. Prioritizing based on value and effort
4. Communicating with stakeholders
5. Adjusting project timeline if needed

Best Practices for UAT Feedback Management

Key Recommendations

• Maintain clear communication channels with users
• Document all feedback systematically
• Establish a clear process for evaluating and prioritizing issues
• Keep stakeholders informed of significant changes
• Plan for timeline adjustments when implementing major changes
• Create a feedback loop to verify fixes

Quality Management Concepts

Core Quality Components

Key Elements

Quality management consists of several essential components:

1. Quality Standards
2. Quality Planning
3. Quality Assurance (QA)
4. Quality Control (QC)

Quality Standards

Standards provide requirements, specifications, or guidelines ensuring that products, processes, or services are fit for achieving desired outcomes. These must be met for project success and should be:

• Clearly defined at project start
• Agreed upon by team and stakeholders
• Measurable and verifiable
• Aligned with organizational goals

Quality Planning

Planning Process

Quality planning involves:

• Identifying relevant quality standards
• Determining how to satisfy these standards
• Creating procedures for quality achievement
• Documenting the quality management approach

Quality Assurance (QA)

QA is an ongoing evaluation process that:

• Reviews project progress toward quality goals
• Includes regular audits
• Ensures procedures are being followed
• Focuses on preventing defects before they occur
• Validates alignment with customer requirements

Quality Control (QC)

QC vs QA

While QA prevents defects, QC focuses on identifying defects after they occur. Quality Control:

• Monitors specific project results
• Determines if they meet quality standards
• Identifies defects after they happen
• Recommends corrective actions
• Validates fixes and improvements

Process Improvement Methodologies

DMAIC Methodology

Definition

DMAIC is a data-driven improvement cycle used to enhance, stabilize, and optimize business processes. It serves as the core tool for driving Six Sigma projects.

The Five Phases of DMAIC

1. Define

   • Identify the problem and improvement needs
   • Set clear, specific goals
   • Document project scope and boundaries
   • Establish stakeholder requirements

2. Measure

   • Quantify the identified issues
   • Gather baseline performance data
   • Validate measurement systems
   • Determine current process capability

3. Analyze

   • Determine root causes
   • Identify key process variables
   • Validate cause-and-effect relationships
   • Prioritize improvement opportunities

4. Improve

   • Develop potential solutions
   • Test and validate improvements
   • Implement change management
   • Document new procedures

5. Control

   • Monitor implemented changes
   • Ensure sustained improvements
   • Standardize successful changes
   • Document lessons learned

PDCA Cycle

Overview

The Plan-Do-Check-Act (PDCA) cycle is a fundamental model for continuous improvement, forming the foundation of Total Quality Management (TQM) and ISO 9001 standards.

Four Stages of PDCA

1. Plan

Planning Phase

• Analyze current inefficiencies
• Identify needs for change
• Assess implementation methods
• Evaluate costs and benefits
• Set clear objectives

2. Do

Implementation Phase

• Execute planned improvements
• Communicate changes clearly
• Manage resistance
• Document progress
• Collect data

3. Check

Evaluation Phase

• Compare results to expectations
• Measure effectiveness
• Identify any gaps
• Document findings
• Gather feedback

4. Act

Action Phase

• Standardize successful changes
• Address any shortcomings
• Plan next improvements
• Share lessons learned
• Update documentation

Quality Management Implementation

Best Practices for Quality Management

Key Success Factors

1. Leadership commitment
2. Employee involvement
3. Process approach
4. Continuous improvement
5. Evidence-based decision making
6. Customer focus

Quality Tools and Techniques

Documentation

• Quality Management Plan
• Process Documentation
• Standard Operating Procedures
• Quality Metrics Dashboard
• Audit Reports

Measurement Tools

• Control Charts
• Pareto Analysis
• Cause-and-Effect Diagrams
• Check Sheets
• Histograms

Quality Review Process

Review Components

1. Regular quality audits
2. Performance metrics tracking
3. Customer feedback analysis
4. Process compliance checks
5. Improvement opportunity identification

Continuous Improvement Cycle

Ongoing Process

The continuous improvement cycle involves:

• Regular assessment of processes
• Identification of improvement opportunities
• Implementation of changes
• Measurement of results
• Standardization of successful changes

Quality Management Integration

Alignment with Project Management

Integration Points

Quality management should be integrated with:

• Project planning
• Risk management
• Change control
• Stakeholder communication
• Resource allocation

Stakeholder Involvement

Engagement Strategies

• Regular quality status updates
• Involvement in quality reviews
• Feedback collection and analysis
• Clear communication of quality metrics
• Collaborative problem-solving

Documentation and Reporting

Key Documents

Maintain comprehensive documentation of:

• Quality standards and requirements
• Process documentation
• Quality metrics and KPIs
• Audit findings and actions
• Improvement initiatives
• Lessons learned

The Agile Manifesto

The Agile values refer to the following four statements:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Agile experts see these values as important underpinnings of the highest performing teams, and every team member should strive to live by these values to apply the full benefits of Agile.

The same is true for the 12 principles, which are at the core of every Agile project:

• “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Whether you are working to create a product for your company or for a customer, chances are that someone is awaiting its delivery. If that delivery is delayed, the result is that the customer, user, or organization is left waiting for that added value to their lives and workflows. Agile emphasizes that delivering value to users early and often creates a steady value stream, increasing you and your customer’s success. This will build trust and confidence through continuous feedback as well as early business value realization.

• “Welcome changing requirements, even late in development.” When working in Agile, it’s important to be agile. That means being able to move swiftly, shifting direction whenever necessary. That also means that you and your team are constantly scanning your environment to make sure necessary changes are factored into the plans. Acknowledging and embracing that your plans may change (once, twice, or several times) ensures that you and your customers are maximizing your success.

• “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Delivering your product in small, frequent increments is important because it allows time and regular opportunities for stakeholders—including customers—to give feedback on its progress. This ensures that the team never spends too much time going down the wrong path.

• “Business people and developers must work together daily throughout the project.” Removing barriers between developers and people focused on the business side of the project, builds trust and understanding and ensures that the developers, or those building the solution, are in tune with the needs of the users.

• “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” A successful Agile team includes team members that not only trust each other to get the work done but are also trusted by their sponsors and executives to get the work done. Teams build better solutions when they are empowered and motivated to deliver difficult projects.

• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” There isn’t anything quite like face-to-face communication. Face-to-face communication allows us to catch certain cues, body language, and facial expressions that are sometimes lost when using forms of communication like email, chat, or the phone. However, we can’t always be face-to-face. Establishing effective communication norms—no matter the format—is essential to effective teams.

• “Working software is the primary measure of progress.” In Agile teams, the main way to demonstrate meaningful completion of work is to show a working piece of the solution. In software teams, that might mean a functional piece of software. In non-software teams, that might mean a critical portion of the solution that is ready to be demonstrated to users or their representatives in order to collect feedback. This is in contrast to traditional or Waterfall projects, where the completion of project documents could be used to measure progress. In Agile project management, it is not enough to say that the team is 80% done with an activity if there is no working, demonstrable artifact available to review.

• “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Maintaining a steady but careful pace will prevent errors along the way. Also, you never want your team to feel overworked or overwhelmed. On the flip side, a team that is underutilized may become bored and lose the creative spark to innovate. The Agile ideal is to achieve a steady pace of effort for the team that avoids overtime and burnout.

• “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Whether you are working to create a product for your company or for a customer, chances are that someone is awaiting its delivery. If that delivery is delayed, the result is that the customer, user, or organization is left waiting for that added value to their lives and workflows. Agile emphasizes that delivering value to users early and often creates a steady value stream, increasing you and your customer’s success. This will build trust and confidence through continuous feedback as well as early business value realization.

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” When working in Agile, it’s important to be agile. That means being able to move swiftly, shifting direction whenever necessary. That also means that you and your team are constantly scanning your environment to make sure necessary changes are factored into the plans. Acknowledging and embracing that your plans may change (once, twice, or several times) ensures that you and your customers are maximizing your success.

• “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Delivering your product in small, frequent increments is important because it allows time and regular opportunities for stakeholders—including customers—to give feedback on its progress. This ensures that the team never spends too much time going down the wrong path.

• “Business people and developers must work together daily throughout the project.” Removing barriers between developers and people focused on the business side of the project, builds trust and understanding and ensures that the developers, or those building the solution, are in tune with the needs of the users. 

• “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” A successful Agile team includes team members that not only trust each other to get the work done but are also trusted by their sponsors and executives to get the work done. Teams build better solutions when they are empowered and motivated to deliver difficult projects.

• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” There isn’t anything quite like face-to-face communication. Face-to-face communication allows us to catch certain cues, body language, and facial expressions that are sometimes lost when using forms of communication like email, chat, or the phone. However, we can’t always be face-to-face. Establishing effective communication norms—no matter the format—is essential to effective teams. 

• “Working software is the primary measure of progress.” In Agile teams, the main way to demonstrate meaningful completion of work is to show a working piece of the solution. In software teams, that might mean a functional piece of software. In non-software teams, that might mean a critical portion of the solution that is ready to be demonstrated to users or their representatives in order to collect feedback. This is in contrast to traditional or Waterfall projects, where the completion of project documents could be used to measure progress. In Agile project management, it is not enough to say that the team is 80% done with an activity if there is no working, demonstrable artifact available to review.

• “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Maintaining a steady but careful pace will prevent errors along the way. Also, you never want your team to feel overworked or overwhelmed. On the flip side, a team that is underutilized may become bored and lose the creative spark to innovate. The Agile ideal is to achieve a steady pace of effort for the team that avoids overtime and burnout.

• “Continuous attention to technical excellence and good design enhances agility.” This principle conveys that just because the team is working fast doesn’t mean they sacrifice quality. By emphasizing quality and design throughout the project development phase, the agility, efficiency, and speed of the team will be increased. When a team delivers a well-built solution, they can quickly respond to user feedback and new information. However, if the product is low quality, implementing changes can become problematic, complex, and slow down the entire team. 

• “Simplicity—the art of maximizing the amount of work not done—is essential.” The team should avoid implementing extra features into the solution that weren’t explicitly requested by the user or product owner. This includes removing procedures that are no longer necessary, and reducing unnecessary documentation. 

• “The best architectures, requirements, and designs emerge from self-organizing teams.” Team members should be able to get their work done by designing their own work processes and practices, without a manager dictating how they operate. Team members should also feel empowered to speak up with questions, concerns, or feedback.

• “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In Agile, it is important to acknowledge that learning from successes and failures is continuous. No team is perfect. There will be mistakes, challenges, trials, and triumphs. Teams should reflect on all of these different aspects of their activities so that they can make necessary adjustments. 

For additional information, read more on the 12 principles here.

The founding principles of Scrum

The original Harvard Business Review paper, written by Hirotaka Takeuchi and Ikujiro Nonaka and titled The New New Product Development Game, introduces Scrum in the chapter “Moving the Scrum downfield.” Throughout the paper, the authors continue to point out which characteristics of a team help to move the Scrum downfield. Those are: 

• Built-in instability: In the Scrum world, teams are given the freedom to achieve important outcomes with “challenging requirements.” Takeuchi and Nonaka explain that this gives teams “an element of tension” necessary to “carry out a project of strategic importance to the company.” 

• Self-organizing teams: Scrum Teams were intended to operate like their own start-up, with a unique order that lacks true hierarchy. These teams are considered self-organizing when they exhibit autonomy, continuous growth, and collaboration.  

• Overlapping development phases: Individuals on a Scrum Team must “work toward synchronizing their pace to meet deadlines.” At some point throughout the process, each individual’s pace starts to overlap with others, and eventually, a collective pace is formed within the team.

• Multi-learning: Scrum is a framework that relies heavily on trial and error. Scrum Team members also aim to stay up-to-date with changing market conditions and can then respond quickly to those conditions. 

• Subtle control: As we mentioned, Scrum Teams are self-organizing and operate like a start-up, but that doesn’t mean there is no structure at all. By creating checkpoints throughout the project to analyze team interactions and progress, Scrum Teams maintain control without hindering creativity. 

• Organizational transfer of learning: On Scrum Teams, everyone is encouraged to learn skills that may be new to them as they support other team members. 

The authors’ main point was that “each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference.” Though these concepts were first introduced in 1986, they still remain remarkably true for Scrum Teams today.

The 2020 Scrum GuideTM

This HTML version of the Scrum Guide is a direct port of the November 2020 version available as a PDF here.

Purpose of the Scrum Guide

We developed Scrum in the early 1990s. We wrote the first version of the Scrum Guide in 2010 to help people worldwide understand Scrum. We have evolved the Guide since then through small, functional updates. Together, we stand behind it.

The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots. As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.

As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.

Scrum Definition

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat

Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.

Scrum Theory

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.

Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.

Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.

Transparency

The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.

Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection

The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.

Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaptation

If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Scrum Values

Successful use of Scrum depends on people becoming more proficient in living five values:

Commitment, Focus, Openness, Respect, and Courage

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.

These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.

Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;

• Instilling quality by adhering to a Definition of Done;

• Adapting their plan each day toward the Sprint Goal; and,

• Holding each other accountable as professionals.

Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;

• Creating and clearly communicating Product Backlog items;

• Ordering Product Backlog items; and,

• Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality;

• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

• Causing the removal of impediments to the Scrum Team’s progress; and,

• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

• Helping find techniques for effective Product Goal definition and Product Backlog management;

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

• Helping establish empirical product planning for a complex environment; and,

• Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;

• Planning and advising Scrum implementations within the organization;

• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

• Removing barriers between stakeholders and Scrum Teams.

Scrum Events

The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.

Optimally, all events are held at the same time and place to reduce complexity.

The Sprint

Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;

• Quality does not decrease;

• The Product Backlog is refined as needed; and,

• Scope may be clarified and renegotiated with the Product Owner as more is learned.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Sprint Planning

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

Sprint Planning addresses the following topics:

Topic One: Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

Topic Two: What can be Done this Sprint?

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Daily Scrum

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Scrum Artifacts

Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

• For the Product Backlog it is the Product Goal.

• For the Sprint Backlog it is the Sprint Goal.

• For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Product Backlog

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.

Commitment: Product Goal

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Sprint Backlog

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Commitment: Sprint Goal

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

Increment

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Work cannot be considered part of an Increment unless it meets the Definition of Done.

Commitment: Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

End Note

Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Great Scrum Team Roles

Product Owner

The Product Owner is responsible for maximizing the product’s value and the work of the Development Team. It’s a one-person role that brings the customer perspective of the product to a Scrum Team.

The Product Owner is responsible for:

• Developing and maintaining a product vision and market strategy
• Product management
• Ordering and managing the Product Backlog
• Involving stakeholders and end-users in Product Backlog refinement and backlog management
• Alignment with other Product Owners when needed from an overall product, company, or customer perspective

A Great Product Owner …

• Embraces, shares and socializes the product vision. A great Product Owner represents the customer’s voice and creates a product vision with the stakeholders. Every decision is taken with the product vision in mind. This ensures sustainable product development, provides clarity for the development team, and increases the chances of product success drastically.

• Exceeds the customer’s expectation. A great Product Owner truly understands the customer’s intentions and goals with the product and is able to outstrip its expectations. Customer delight is the ultimate goal!

• Is empowered. A great Product Owner is empowered to make decisions related to the product. Sure, creating support for their decisions might take some time, but swiftly making important decisions is a primary condition for a sustainable pace of the development team.

• Orders the product backlog. A great Product Owner understands that the product backlog should be ordered. Priority, risk, value, learning opportunities, and dependencies are all taken into account and balanced with each other. For example, when building a house, the roof might have the highest priority considering possible rain. But still, it’s necessary to build the foundation and walls earlier and therefore prioritize them above the construction of the roof.

• Prefers face-to-face communication. A great Product Owner understands that the best way to convey information is face-to-face communication. User stories are explained in a personal conversation. If a tool is used for backlog management, its function is to support the dialogue. It never replaces good old-fashioned conversation.

• Knows modeling techniques. A great Product Owner has a backpack full of valuable modeling techniques. They know when to apply a specific model. Examples are Business Model Generation, Lean Startup, or Impact Mapping. Based on these models they know how to drive product success.

• Shares experiences. A great Product Owner shares experiences with peers. This might be within the organization, and outside it: seminars and conferences are a great way to share experiences and gather knowledge. In addition, writing down lessons learned can be valuable for other Product Owners.

• Owns user-story mapping. A great Product Owner should master the concept of user-story mapping. It’s a technique that adds a second dimension to your backlog. This visualization shows the big picture of the product backlog. Jeff Patton has written some excellent material about the concept of story mapping.

• Has a focus on functionality. A great Product Owner has a focus on functionality and the non-functional aspects of the product. Hours or even story points are less important. The goal of the Product Owner is to maximize value for the customer. It’s the functionality that has value; therefore, this is the main focus for the Product Owner.

• Is knowledgeable. A great Product Owner has in-depth (non-)functional product knowledge and understands the technical composition. For large products, it might be difficult to understand all the details, and scaling the Product Owner role might be an option. However, the Product Owner should always know the larger pieces of the puzzle and hereby make conscious, solid decisions.

• Understands the business domain. A great Product Owner understands the domain and environment they are part of. A product should always be built with its context taken into account. This includes understanding the organization paying for the development but also being aware of the latest market conditions. Shipping an awesome product after the window of opportunity closes is quite useless.

• Acts on different levels. A great Product Owner knows how to act on different levels. The most common way to define these levels is strategic, tactical, and operational. A Product Owner should know how to explain the product strategy at board level, create support at middle management, and motivate the development team with their daily challenges.

• Knows the 5 levels of Agile planning. Within Agile, planning is done continuously. Every product needs a vision (level 1) which will provide input to the product roadmap (level 2). The roadmap is a long-range strategic plan of how the business would like to see the product evolve. Based on the roadmap, market conditions, and status of the product the Product Owner can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team’s progress towards realizing the Sprint Goal.

• Is available. A great Product Owner is available to the stakeholders, the customers, the development team, and the Scrum Master. Important questions are answered quickly and valuable information is provided on time. The Product Owner ensures that their availability never blocks the progress of the development team.

• Is able to say ‘No’. A great Product Owner knows how and when to say no. This is probably the most obvious - but most difficult - characteristic to master. Saying yes to a new idea or feature is easy; it’s just another item for the product backlog. However, good backlog management encompasses creating a manageable product backlog with items that probably will get realized. Adding items to the backlog knowing nothing will happen with them only creates ‘waste’ and false expectations.

• Acts as a “Mini-CEO”. A great Product Owner basically is a mini-CEO for their product. They have a keen eye for opportunities, focus on business value and the Return On Investment and act proactively on possible risks and threats. Everything with the growth (size, quality, market share) of the product taken into account.

• Knows the different types of valid Product Backlog items. A great Product Owner can clarify the fact that the Product Backlog consists of more than only new features. For example: technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account.

• Takes Backlog Refinement seriously. A great Product Owner spends enough time refining the Product Backlog. Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. The outcome should be a Product Backlog that is granular enough and well understood by the whole team. On average the Development Team spends no more than 10% of the capacity of the Development Team on refinement activities. The way refinement is done isn’t prescribed and is up to the team. The Product Owner can involve stakeholders and the Development Team in backlog refinement. The stakeholders are involved because it gives them the opportunity to explain their wishes and desires. The Development Team is able to clarify functional and technical questions or implications. This approach ensures common understanding and increases the quality of the Product Backlog considerably. As a consequence, the opportunity to build the right product with the desired quality will also increase.

Scrum Master

According to the Scrum Guide the Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on the situation and context. All that the Scrum Master does has the purpose of helping people understand and better apply the Scrum framework.

The Scrum Master acts as a:

• Servant Leader whose focus is on the needs of the team members and those they serve (the customer), with the goal of achieving results in line with the organization’s values, principles, and business objectives
• Facilitator by setting the stage and providing clear boundaries in which the team can collaborate
• Coach by coaching individuals with a focus on mindset and behavior: the team in continuous improvement, and the organization in truly collaborating with the Scrum team
• Conflict navigator to address unproductive attitudes and dysfunctional behaviors
• Manager responsible for managing impediments, eliminate waste, managing the process, managing the team’s health, managing the boundaries of self-organization, and managing the culture
• Mentor that transfers Agile knowledge and experience to the team
• Teacher to ensure Scrum and other relevant methods are understood and enacted

A Great Scrum Master …

• Involves the team with setting up the process. A great Scrum Master ensures the entire team supports the chosen Scrum process and understands the value of every event. The daily Scrum, for example, is planned at a time that suits all team members. A common concern about Scrum is the amount of ‘meetings’ involving the team with planning the events and discussing the desired outcome will increase engagement for sure.
• Understands team development. A great Scrum Master is aware of the different phases a team will go through when working as a team. They understand Tuckman’s different stages of team development: forming, storming, norming, performing, and adjourning. The importance of a stable team composition is also clear.
• Understands principles are more important than practices. Without a solid, supported understanding of the Agile principles, every implemented practice is basically useless. It’s an empty shell. An in-depth understanding of the Agile principles by everyone involved will increase the chances of successful usage of practices drastically.
• Recognizes and acts on team conflict. A great Scrum Master recognizes team conflict in an early stage and can apply different activities to resolve it. A great Scrum Master understands conflict isn’t necessarily wrong. Healthy conflict and constructive disagreement can be used to build an even stronger team.
• Dares to be disruptive. A great Scrum Master understands some changes will only occur by being disruptive. They know when it’s necessary and is prepared to be disruptive enough to enforce a change within the organization.
• Is aware of the smell of the place. A great Scrum Master can have an impact on the culture of the organization so that the Scrum teams can really flourish. They understand that changing people’s behavior isn’t about changing people, but changing the context which they are in: the smell of the place.
• Is both dispensable and wanted. A great Scrum Master has supported the growth of teams in such a manner they don’t need them anymore on a daily basis. But due to their proven contribution they will get asked for advice frequently. Their role has changed from a daily coach and teacher to a periodical mentor and advisor.
• Let their team fail (occasionally). A great Scrum Master knows when to prevent the team from failing but also understands when they shouldn’t prevent it. The lessons learned after a mistake might be more valuable than some good advice beforehand.
• Encourages ownership. A great Scrum Master encourages and coaches the team to take ownership of their process, task wall and environment.
• Has faith in self-organization. A great Scrum Master understands the power of a self-organizing team. “Bring it to the team” is their daily motto. Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work. Some examples are: they make their own decisions about their work, estimate their own work, have a strong willingness to cooperate and team members feel they are coming together to achieve a common purpose through release goals, sprint goals, and team goals.
• Values rhythm. A great Scrum Master understands the value of a steady sprint rhythm and does everything to create and maintain it. The sprint rhythm should become the team’s heartbeat, which doesn’t cost any energy. Everyone knows the date, time and purpose of every Scrum event. They know what is expected and how to prepare. Therefore a complete focus on the content is possible.
• Knows the power of silence. A great Scrum Master knows how to truly listen and is comfortable with silence. Not talking, but listening. They are aware of the three levels of listening - level 1 internal listening, level 2 focused listening, level 3 global listening, and knows how to use them. They listen carefully to what is said, but also to what isn’t said.
• Observes. A great Scrum Master observes their team with their daily activities. They don’t have an active role within every session. The daily Scrum, for example, is held by the team for the team. They observe the session and hereby has a more clear view to what is being discussed (and what isn’t) and what everyone’s role is during the standup.
• Shares experiences. Great Scrum Masters shares experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down and sharing your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner and the Development Team.
• Has a backpack full of different retrospective formats. A great Scrum Master can apply lots of different retrospective formats. This ensures the retrospective will be a fun and useful event for the team. They know what format is most suitable given the team’s situation. Even better: they support the team by hosting their own retrospective. To improve involvement this is an absolute winner!
• Can coach professionally. A great Scrum Master understands the power of professional coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active Coaching don’t have any secrets for them. They know how to guide without prescribing. They can close the gap between thinking about doing and actually doing; they can help the team members understand themselves better so they can find new ways to make the most of their potential. Yes, these last few sentences are actually an aggregation of several coaching definitions, but it sounds quite cool!
• Has influence at organizational level. A great Scrum Master knows how to motivate and influence at tactic and strategic level. Some of the most difficult impediments a team will face occur at these levels; therefore it’s important a Scrum Master knows how to act at the different levels within an organization.
• Prevent impediments. A great Scrum Master not only resolves impediments, they prevent them. Due to their experiences they are able to ‘read’ situations and hereby act on them proactively.
• Isn’t noticed. A great Scrum Master isn’t always actively present. They don’t disturb the team unnecessarily and supports the team in getting into the desired ‘flow’. But when the team needs them, they are always available.
• Forms a great duo with the Product Owner. A great Scrum Master has an outstanding partnership with the Product Owner. Although their interests are somewhat different, the Product Owner ‘pushes’ the team, the Scrum Master protects the team. A solid partnership is extremely valuable for the Development Team. Together they can build the foundation for astonishing results.
• Allows leadership to thrive. A great Scrum Master allows leadership within the team to thrive and sees this as a successful outcome of their coaching style. They believe in the motto “leadership isn’t just a title, it’s an attitude”. And it’s an attitude everyone in the team can apply.
• Is familiar with gamification. A great Scrum Master is able to use the concepts of game thinking and game mechanics to engage users in solving problems and increase users’ contribution.
• Understands there’s more than just Scrum. A great Scrum Master is also competent with XP, Kanban and Lean. They know the strengths, weaknesses, opportunities and risks of every method/framework/principle and how & when to use them. They try to understand what a team wants to achieve and helps them become more effective in an Agile context.
• Leads by example. A great Scrum Master is someone that team members want to follow. They do this by inspiring them to unleash their inner potential and showing them the desired behavior. At difficult times, they show them how to act on it; they don’t panic, stay calm, and help the team find the solution.
• Is a born facilitator. A great Scrum Master has facilitation as their second nature. All the Scrum events are a joy to attend, and every other meeting is well prepared, useful and fun, and has a clear outcome and purpose.

Development Team

According to the Scrum Guide the Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

• Self-organizing. They decide how to turn Product Backlog Items into working solutions.
• Cross-functional. As a whole, they’ve got all the skills necessary to create the product Increment.
• No titles. Everyone is a Developer, no one has a special title.
• No sub-teams in the Development team.
• Committed to achieving the Sprint Goal and delivering a high-quality increment

A Great Development Team …

• Pursues technical excellence. Great Development Teams use Extreme Programming as a source of inspiration. XP provides practices and rules that revolve around planning, designing, coding, and testing. Examples are refactoring (continuously streamlining the code), pair programming, continuous integration (programmers merge their code into a code baseline whenever they have a clean build that has passed the unit tests), unit testing (testing code at development level) and acceptance testing (establishing specific acceptance tests).
• Applies team swarming. Great Development Teams master the concept of ‘team swarming’. This is a method of working where a team works on just a few items at a time, preferably even one item at a time. Each item is finished as quickly as possible by having many people work on it together, rather than having a series of handoffs.
• Uses spike solutions. A spike is a concise, timeboxed activity used to discover work needed to accomplish a large ambiguous task. Great Development Teams uses spike experiments to solve challenging technical, architectural, or design problems.
• Refines the product backlog as a team. Great Development Teams consider backlog refinement a team effort. They understand that the quality of the Product Backlog is the foundation for a sustainable development pace and building great products. Although the Product Owner is responsible for the product backlog, it’s up to the entire team to refine it.
• Respects the Boy Scout Rule. Great Development Teams use the Scout Rule: always leave the campground cleaner than you found it. Translated to software development: always leave the code base in a better state than you’ve found it. If you find messy code, clean it up, regardless of who might have made the mess.
• Criticizes ideas, not people. Great Development Teams criticize ideas, not people. Period.
• Share experiences. Great Development Teams share experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course, writing down and sharing your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner.
• Understands the importance of having some slack. Great Development Teams have some slack within their sprint. Human beings can’t be productive all day long. They need time to relax, have a chat at the coffee machine or play table football. They need some slack to be innovative and creative. They need time to have some fun. By doing so, they ensure high motivation and maximum productivity. But slack is also necessary to handle emergencies that might arise; you don’t want your entire sprint to get into trouble when you need to create a hot-fix. Therefore: build in some slack! And when the sprint doesn’t contain any emergencies: great! This gives the team the opportunity for some refactoring and emergent design. It’s a win-win!
• Has fun with each other. Great Development Teams ensure a healthy dose of fun is present every day. Fostering fun, energy, interaction and collaboration creates an atmosphere in which the team will flourish!
• Don’t have any Scrum ‘meetings’. Great Development Teams consider Scrum events as opportunities for conversations. Tobias Mayer describes this perfectly in his book ‘The People’s Scrum’: “Scrum is centered on people, and people have conversations. There are conversations to plan, align, and to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations, we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection).”
• Knows their customer. Great Development Teams know their real customer. They are in direct contact with them. They truly understand what they desire and are therefore able to make the right (technical) decisions.
• Can explain the (business) value of non-functional requirements. Great Development Teams understand the importance of non-functional requirements such as  performance, security, and scalability. They can explain the (business) value to their Product Owner and customer and thereby ensure its part of the product backlog.
• Trust each other. Great Development Teams trust each other. Yes, this is obvious. But, without trust, it’s impossible for a team to achieve greatness.
• Keep the retrospective fun. Great Development Teams think of retrospective formats themselves. They support the Scrum Master with creative, fun, and useful formats and offer to facilitate the sessions themselves.
• Deliver features during the sprint. Great Development Teams deliver features continuously. Basically, they don’t need sprints anymore. Feedback is gathered and processed whenever an item is ‘done’; this creates a flow of continuous delivery.
• Don’t need a sprint 0. Great Development Teams don’t need a sprint 0 before the ‘real’ sprints start. They can deliver business value in the first sprint.
• Acts truly cross-functional. Great Development Teams not only have a cross-functional composition, they truly act cross-functionally. They don’t talk about different roles within the team but are focused on delivering a releasable product for every sprint as a team. Everyone is doing the stuff that’s necessary to achieve the sprint goal.
• Updates the Scrum board themselves. Great Development Teams ensure the Scrum/team board is always up-to-date—it’s an accurate reflection of reality. They don’t need a Scrum Master to encourage them; instead, they collaborate with the Scrum Master to update the board.
• Spends time on innovation. Great Development Teams understand the importance of technical/architectural innovation. They know it’s necessary to keep up with the rapidly changing environment and technology. They ensure they have time for innovation during regular working hours, and that it’s fun and exciting!
• Don’t need a Definition of Done. Great Development Teams deeply understand what ‘done’ means for them. For the team members, writing down the Definition of Done isn’t necessary anymore. They know. The only reason to use it is to make the ‘done state’ transparent for their stakeholders.
• Knows how to give feedback. Great Development Teams have learned how to give each other feedback honestly and respectfully. They grasp the concept of the ‘Situation - Behavior - Impact Feedback Tool’ and therefore provide clear, actionable feedback. They give feedback whenever it’s necessary and don’t postpone feedback until the retrospective.
• Manages their team composition. Great Development Teams manage their own team composition. Whenever specific skills are necessary, they collaborate with other teams to discuss the opportunities of ‘hiring’ specific skills.
• Practice collective ownership. Great Development Teams understand the importance of collective ownership. Therefore, they rotate developers across different modules of the applications and systems to encourage collective ownership.
• Fix dependencies with other teams. Great Development Teams are aware of possible dependencies with other teams and manage these by themselves. This approach  ensures a sustainable development pace for the product.
• Don’t need story points. Great Development Teams don’t focus on story points anymore. They’ve refined the product backlog so that the size for the top items doesn’t vary much. They know how many items they can realize each sprint. Counting the number of stories is enough for them. .

The elements of user stories and epics

User stories

The driving factor behind every Scrum project is putting the customer first. User stories are a key component of ensuring that customers are satisfied with the product. A team writes a user story from the perspective of the user. Not only do user stories provide insight into what goals the user wants to achieve, but they enable collaboration, inspire creative solutions, and create momentum by giving the team a small win when the stories are developed. 

When writing user stories, you will need to include the following elements: 

• User persona. What is your user like? What is their relation to the project? What goals do they have? 

• Definition of Done. This refers to an agreed upon set of items that must be completed before a user story can be considered complete. 

• Tasks. What are the key activities needed to complete the user story?

• Any feedback already provided. If you are adding features to an existing product and you have already received feedback from customers on a past iteration, make sure to consider this feedback.  

I.N.V.E.S.T. 

Recall from the video that your user stories should meet the I.N.V.E.S.T. criteria: 

• Independent: The story’s completion is not dependent on another story.

• Negotiable: There is room for discussion about this item.

• Valuable: Completing the user story has to deliver value. 

• Estimable: The Definition of Done must be clear so that the team can give each user story an estimate. 

• Small: Each user story needs to be able to fit within a planned Sprint.

• Testable: A test can be conducted to check that it meets the criteria.

Let’s imagine you are working on a project for a local library. The library hopes to launch a website so that customers can read reviews before they check out books from the branch. The typical template for a user story looks like this: As a user role, I want this action so that I can get this value. Therefore, an example user story for this situation might read: As an avid reader, I want to be able to read reviews before I check out a book from my local branch so that I know I am getting a book I am interested in.

Epics

An epic’s purpose is to help manage related user stories. In this post, Mike Cohn, the inventor of the term “epic” as it relates to Scrum, describes epic as a “very large user story”—one that could not be delivered within a single iteration and may need to be split into smaller stories. The team should discuss together and reach a shared view of how to write and capture their user stories and epics. Keep in mind, epics are just larger user stories that are there to help organize the project. 

Let’s imagine you are creating user stories and epics based on the previous example. User stories may include customers wanting to read reviews of books on the website or wanting to add books to their cart. These user stories could fall into the “website creation” epic. 

Another user story could be that customers want to walk into the library and easily find the non-fiction section. This would fall under the “organization of the physical space” epic.

So rather than those various user stories appearing in a list together, they are organized into sections, or epics.

Agile effort estimation techniques

Planning Poker™

This particular method is well-known and commonly used when Scrum teams have to make effort estimates for a small number of items (under 10). Planning Poker is consensus-based, meaning that everyone has to agree on the number chosen. In this technique, each individual has a deck of cards with numbers from the Fibonacci sequence on them. The Fibonacci sequence is where a number is the sum of the last two numbers (e.g., 0, 1, 1, 2, 3, 5, 8, 13, and so on). 

Sometimes, Planning Poker decks also include cards with coffee cups and question marks on them. The question mark card means that the person doesn’t understand what is being discussed or doesn’t have enough information to draw a conclusion. The coffee cup card means that the person needs a break.

The Planning Poker strategy is used in Sprint Planning meetings. As each Product Backlog item/user story is discussed, each team member lays a card face down on the table. Then, everyone turns their card over at the same time and the team discusses the estimates, particularly when they are far apart from one another. By first hiding the estimates, the group avoids any bias that is presented when numbers are said aloud. Sometimes, when hearing numbers aloud, people react to that estimate or the estimator themselves, and it changes what their initial thought may have been. In Planning Poker, teams can easily avoid that bias.

Dot Voting 

Dot Voting, like Planning Poker, is also good for sprints with a low number of Sprint Backlog items. In Dot Voting, each team member starts with small dot stickers, color-coded by the estimated effort required (e.g., S=green, M=blue, L=orange, XL=red). The items or user stories are written out on pieces of paper placed around a table or put up on the wall. Then, team members walk around the table and add their colored stickers to the items. 

The Bucket System

The Bucket System is helpful for backlogs with many items since it can be done very quickly. In fact, a couple hundred items can be estimated in just one hour with the Bucket System. The Bucket System is an effective strategy for sizing items because it explores each item in terms of pre-determined “buckets” of complexity. Keep in mind that these buckets are metaphorical; this strategy doesn’t require the use of actual buckets, and instead uses sticky notes or note cards as buckets.

In this technique, the team starts by setting up a line of note cards down the center of the table, each marked with a number representing a level of effort. Then, the team writes each item or user story on a card. Each person draws and reads a random item,  then places it somewhere along the line of numbered note cards. There is no need to discuss further with the team. If a person draws an item that they do not understand, then they can offer it to someone else to place. Additionally, if a person finds an item that they think does not fit where it was placed, they can discuss it with the team until a consensus about a more accurate placement is reached. Team members should spend no more than 120 seconds on each item.  

Large/Uncertain/Small 

Large/Uncertain/Small is another quick method of rough estimation. It is great for product backlogs that have several similar or comparable items. 

This is the same general idea as the Bucket System, but instead of several buckets, you only use three categories: large, uncertain, and small. Starting with the simpler, more obvious user stories, the team places the items in one of the categories. Then, the team discusses and places more complex items until each is assigned to a category.

Ordering Method

The Ordering Method is ideal for projects with a smaller team and a large number of Product Backlog items. First, a scale is prepared and items are randomly placed ranging from low to high. Then, one at a time, each team member either moves any item one spot lower or higher on the scale or passes their turn. This continues until team members no longer want to move any items. 

Affinity Mapping

Affinity Mapping is useful for teams that have more than 20 items in their Product Backlog. 

A best practice is to conduct this technique using sticky notes placed onto a wall, whiteboard, or table. Each sticky note features a different user story or item. Using sticky notes allows the team to move user stories around in order to group them by similar theme, group, and pattern. The team begins by placing one sticky note on the board. Then, the team takes the next sticky note and discusses whether it is similar to the first item. Based on the team’s assessment, the second sticky note is placed in the first group or into its own group. 

After all of the items are grouped (there should be anywhere from 3–10 groups total), the team gives a name to each group that represents the general theme of the items. Then, the groups are prioritized by importance so that the team knows which items to tackle first. 

Characteristics of effective estimation

Regardless of which technique your team chooses, there are several important characteristics the techniques share that lead to effective estimation:

• Avoids gathering false precision of estimates. In Scrum, assigning rough estimates results in more accuracy across the project. Therefore, if the team focuses on identifying relative estimates—rather than a team having a lengthy debate about whether a task will take seven or 10 days of work—the team saves time and avoids potentially missing deadlines.

• Avoids anchoring bias. Many of these techniques (e.g., Planning Poker) keep the initial estimate private, which allows team members to form an independent opinion on the estimate before sharing their thoughts with the team. This prevents a known phenomenon called anchoring bias, where individuals find themselves compelled to put forth estimates similar to others in the room to avoid embarrassment. 

• Promotes inclusivity. These group estimation techniques not only lead to better estimates but also help the team develop trust and cohesiveness.

• Leads to effort discovery. Estimating in these dynamic ways can help the team uncover strategies to get items completed which might otherwise not have been revealed.

T-shirt sizes and story points

As a recap, relative estimation means to compare the effort estimated for completing a backlog item to the effort estimated for another backlog item. Doing this instead of trying to determine exactly how long a task will take allows your comparisons and estimates to be more accurate relative to one another.

T-shirt sizes

At first, T-shirt sizes may seem like a somewhat unusual way to measure an item or user story. But when you think about assigning estimations to items based on sizes (e.g., XS, S, M, L, XL, XXL), it is actually very helpful and easy. Some of the benefits to using this technique are that it is quick, well understood by Agile experts, and a good introduction for teams who are just learning relative estimation.

So what does the process of assigning T-shirt sizes entail? There are several specific techniques a team can try, but each generally follows these steps. The team: 

• Agrees on the chosen scale and metrics to be used.

• Identifies at least one anchor backlog item. That item will be assigned a T-shirt size. Some teams will choose two anchor items—one at the top of the range and one at the bottom of the range.

• Sorts through the remaining backlog items and agrees on T-shirt sizes for each of them. 

Story points

Using story points as the estimate unit is a little more advanced than T-shirt sizes, but it is essentially the same concept. This method is good for experienced teams. When using story points, teams usually use the Fibonacci sequence. As a reminder, this sequence comes from adding the two previous numbers in the sequence together. For example, 1 + 2 = 3 and 2 + 3 = 5. The important thing to notice about this sequence is that, as the list continues on, the numbers spread further apart from each other. Because of this, story points provide more accuracy and specificity than T-shirt sizes. 

So what does the process of assigning story points entail? There are several specific techniques a team can try, but the basic steps are the same as with T-shirt sizes. The team: 

• Agrees on the permitted points values. Some teams cap the size at a certain number, like 21. Some teams decide to jump from 21 to 100 as the next larger value. This is a team decision.

• Identifies at least one anchor backlog item and agrees to assign it a points value. Some teams will choose two anchor items, one at the top of the range and one at the bottom of the range.

• Sorts through the remaining backlog items as a team, agrees on an estimate for each item, and captures it in the backlog management system. 

Best practices

Some best practices, regardless of the technique you use, include:

• Asking the Product Owner questions about the user story or item to ensure that there is enough information to estimate it.

• Discussing divergent estimates from various team members so that everyone has a chance to understand how to implement the item.

• Agreeing on the final T-shirt sizes or points value and capturing it in the system.

• If certain items fall into the larger T-shirt size or story points value range, discussing whether it makes sense to break them down into smaller pieces before moving on.