Your Scrum 2020 Practice Guide
Do you know what Scrum is and how to use it? As a project manager or a specialist you MUST get on-board!
Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
First, A Quick Overview of Scrum
Scrum is a simple framework for building innovative solutions. Scrum is a single-team process framework used to manage product development. The framework consists of Scrum roles, events, artifacts, and rules, and uses an iterative approach to deliver working product.
Scrum is founded on empirical process control theory, or empiricism, and this asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Transparency Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard, so observers share a common understanding of what is being seen.
Inspection Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaptation If an inspection determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum prescribes four formal events for inspection and adaptation:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive.
Scrum is run on timeboxes of 1 month or less with consistent durations called sprints where a potentially releasable increment of product is produced.
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.
Scrum makes clear the relative efficiency of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
There are 3 Scrum roles: Product Owner, Scrum Master and Development Team.
The Product Owner helps connect the team with SMEs and stakeholders and prioritizes the backlog of features that need to be built.
The Scrum team consists of a product owner, development team, and scrum master. The product owner is responsible for maximizing the value of the product.
The development team is a cross-functional, self-organizing team consisting of team members who have everything they need within the team to deliver working product without depending on others outside of the team.
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.
A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
Development Teams have the following features: They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment.Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person.Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis.Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
The Development Team does all the work required to convert the backlog into working solutions.
So, they need to have all the skill-sets required to deliver the solution end to end without hand-offs. Depending on the product, the team could include members with strengths in design, testing, analysis, development, and databases.
Scrum teams use a timeboxed iteration called a sprint to keep them focused and work in short cycles. Most teams use a 2-week sprint although the sprint length can vary from one to four weeks.
Teams start the sprint with a planning meeting where the Product Owner identifies the priorities for the sprint and the Development Team plans in detail how to accomplish those priorities.
At the end of the sprint, the Development Team holds a review which is an opportunity to showcase the incremental solution that has been built and get feedback from users and stakeholders.
Finally, the Team holds a retrospective meeting at the end of the sprint where they examine their processes and identify improvements to make the team more effective and enjoyable. Then they immediately begin the next sprint and the cycle continues
The Scrum Master
The Scrum Master is a coach and servant leader who removes impediments and helps the team to self-organize and use Scrum effectively. The scrum master is responsible for ensuring the Scrum process is upheld and works to ensure the Scrum team adheres to the practices and rules as well as coaches the team on removing impediments.
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team and helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which are not. They help everyone change these interactions to maximize the value created by the Scrum Team.
The Product Owner
The Product Owner is one person and for them to succeed, the entire organization must respect their decisions.
They are responsible for maximizing the value of the product resulting from work of the Development Team and is the sole person responsible for managing the Product Backlog.
Product Backlog management includes:
- Clearly expressing Product Backlog items
- Ordering the items in the Product Backlog to best achieve goals and missions
- Optimizing the value of the work the Development Team performs
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
- Ensuring the Development Team understands items in the Product Backlog to the level needed
Don’t let the simplicity of the Scrum Framework fool you. Many people say they understand Scrum, but the reality is that they don’t.
They don’t understand it because they look at the simple scrum framework through the lens of what they currently do. Until they practice Scrum, they won’t understand it.
Most of what people currently do using a traditional or waterfall approach is not included in the Scrum Framework. A casual read through of the Scrum Guide can leave people thinking they understand Scrum.
It can also lead people to believe that Scrum means everything that they add daily stand-ups and a few other meetings to their existing, heavy, waterfall process. Adopting Scrum frequently means stopping doing a lot of things that teams are currently doing.
This lack of understanding of Agile and Scrum is a key reason that teams moving from waterfall to Scrum stumble. They often continue to operate in the same ways as before, but simply call it by the names found in the Scrum framework.
These organizations rename their project managers Scrum Masters. They start having a daily status meeting that they call daily stand-up.
Implementing Scrum
Vision Hierarchy
First, your enterprise’s vision needs to be shared with everyone in your organization in a “connected” way: everything your people do, all the way down to the task level of individual work, needs to connect back to the vision.
This is harder than one may think. Leadership can tell and sell the vision, but that doesn’t necessarily get everyone’s buy-in. The vision sharing exercise is a vision formation exercise with your people.
Epic, Story, Task are Scrum terms that help people think of all crucial things in a product or project that needs to be built or done to realize the shared vision. By design, Scrum puts everyone on the same page by doing this “Backlog” creation exercise along the vision hierarchy.
Running Sprints
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created. Sprints have consistent duration throughout a development effort.
As a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
Other than the Sprint which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something.
A new Sprint starts immediately after the conclusion of the previous Sprint.
The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve, and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.
The Scrum Master ensures that the event takes place and that attendants understand its purpose and teaches the Scrum Team to keep it within the time-box. Sprint Planning answers – What can be delivered in the Increment resulting from the upcoming Sprint? and How will the work needed to deliver the Increment be achieved?
Sprint Goal
During Sprint Planning, the Scrum Team also defines the Sprint Goal.
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment and is created during the Sprint Planning meeting.
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint.
The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.
During the Sprint:
- No changes are made that would endanger the Sprint Goal
- Quality goals do not decrease
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something, as each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
Scrum is a “time constrained” project management framework comprised of Sprints, where you set a recurring fixed period of work cycle, typically somewhere between one to four weeks, according to the characteristic of your team’s work. The approach is to do things in small increments and fast iterations, with strong emphasis on reviewing work to help the team move towards the goal.
Backlog
Think of everything that could possibly be included in the product or needs to be done in the project. Tread the path of the user journey: User Stories are a great way of contextualizing customer wants and needs.
User Story: As a [user], I want [what], so that [value]
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Backlog evolves as the product and the environment in which it will be used evolves.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.
The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. As new work is required, the Development Team adds it to the Sprint Backlog.
As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
Sprint Planning
Prioritize and estimate the Backlog, decide what to do in the coming Sprint.
For estimation of how long it will take to get each job done, Planning Poker is usefulThe Kanban Board (or Scrum Board) is a key item in Scrum. This is where information is persistently displayed, visualized and shared with the team. Customization is encouraged to fit the team’s workflow
Definition of Done is another must observance in Scrum. Definition of Done is not just a quality assurance notion for fellow Sprint team members to verify work before releaseThere are two facilitator leader roles in Scrum. The first is the Product Owner, the “what” guy, and the second is the Scrum Master, the “how” guy. The key is facilitation — the Scrum team’s productivity is measured in “velocity”, or how fast they can get things done, and it’s most productive to facilitate team members to individually and collectively make decisions on what to do and how to do things, rather than instructing them as in a traditional hierarchical organization.
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.
By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
An increment is a body of inspect-able, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in usable condition regardless of whether the Product Owner decides to release it.
Daily Stand Up
A typical Scrum team should be somewhere between 3 to 9 people, plus the Product Owner and Scrum Master. Anything larger, the team’s velocity drops so it’s best to split into different Scrum teams.
The key to velocity is rich communication between team members on progress and impediments. A fixed format Daily Stand Up is proven to be highly effective for this purpose: every day at the same time, for less than 15 minutes, the team gathers in front of the Kanban Board, and each team member shares their progress by answering the following three questions:
- What work was done yesterday?
- What work is planned for today?
- Any impediments in the way?
This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.
The Daily Stand Up
This is NOT a status update meeting for the manager to find out who is behind schedule or to give job instructions. Status updates only give snap shots — what’s important is to check-in on the flow.
The Stand Up is for the team to understand what work has been done and what work remains, so that people can accelerate teamwork. If someone is stuck, fellow team members come in to help. And if necessary, the Scrum Master re-plans workflow to facilitate obstacle removal.
Sprint Review and Retrospective
At the end of each Sprint, the Scrum Team does two meetings.The first is the “what” meeting: the Sprint Review to go over what was done in the last Sprint, facilitated by the Product Owner. This meeting often accompanies demos of new releases and other accomplishments, and members from the rest of the organization are welcomed to join.
The second is the “how” meeting: the Sprint Retrospective. This is for the Scrum team members to reflect and discuss the impediments that surfaced during the last Sprint, and even if things are going well, ideas for improvement. The Scrum Owner facilitates this meeting by making sure the focus remains on fixes to the process and not on people blaming.
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.
Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is at most a four-hour meeting for one-month Sprints.
The Sprint Review includes the following elements:
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
- The Development Team demonstrates the work that it has “Done” and answers questions about the Increment
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed)
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
There is a review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do nextA review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints.
The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people, relationships, process, and tools
- Identify and order the major items that went well and potential improvements
- Create a plan for implementing improvements to the way the Scrum Team does its work
At the end of both meetings, the team updates the Backlog and plans for the next Sprint.
Artifact Transparency
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis.
If artifacts are NOT completely transparent, these decisions can be flawed, value may reduce and risk may increase.
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent.
Definition of “Done”
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
Development Teams deliver an Increment of product functionality every Sprint. This Increment is usable, so a Product Owner may choose to immediately release it.
The Burn Down Chart
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is on the vertical axis, with time along the horizontal. It is a run chart of outstanding work. It is useful for predicting when all the work will be completed.
Outstanding work can be represented in terms of either time or story points.
Scrum Benefits to Your Organization
Transparency – Scrum teams use various tools to track their status and all information is publicly available. There is no pressure on teams to embellish their status reports
Predictability – Stable teams that work in consistent, timeboxed iterations produce predictable results. The throughput of the team can be used to accurately forecast the completion of the project or the next release
Responsiveness to Change – Scrum teams plan in detail for just the next time-boxed iteration which is usually 2-3 weeks. If priorities or requirements change, those changes can be easily incorporated into the next iteration without creating waste or rework
Focus & Alignment – All team members are dedicated to just one team. Each team is pulling from a backlog that has been prioritized by the Product Owner who is the key business decision maker. This aligns the goals of the team with the true needs of the business
Control – By focusing the work of the teams on the product backlogs, leaders can control the flow of work that the teams are doing. In most organizations, it is likely that team members will be asked to work on things – and are often pulled into firefighting. Moving to Scrum is an opportunity to eliminate this hidden work
Stronger and More Capable Employees and Teams – By empowering and trusting the Scrum team members, we get stronger and more capable employees which leads to business agility
Simplicity – Once backlogs are set up and teams are completing the work of the backlogs, there is very little management work that needs to be done. Traditional resource management, task management, meetings and other management behaviors are minimized or eliminated
Ability for Managers to Focus on Strategic Issues – The above point has a further benefit – it allows managers and leaders to focus on what is really important. Once we empower teams to self-organize, leaders can let go and begin to focus on the important issues such as governance and leadership
Scrum Benefits to YOU
Clarity of purpose and contribution – Teams that are working together on a product backlog have a clarity of purpose that is often lacking when team members are playing a small role on multiple projects
Full ownership – Scrum team members see things all the way through to done and collectively own the solution
Learning and growth – The Scrum framework promotes continual improvement and learning, and most Scrum teams also dedicate some portion of their capacity to learning
Focus – The Scrum Framework provides focus and discipline. Team members are not distracted and work steadily on backlog items in priority order until they are done
Greater autonomy and motivation – Teams can self-organize within the Scrum Framework. They choose the tasks and work together to make decisions on how to proceed without a manager or project manager directing their work
End to end Ownership – Scrum teams have all the skill-sets needed to develop the solutions. They avoid interim deliverables and hand-offs to other teams – also helping with predictability
Community and social needs – Some folks prefer to work alone yet we all have social and community needs that are met through being a part of one Scrum team
Greater levels of engagement and motivation – All the above points contribute to a higher level of employee engagement and motivation which is typical in organizations using Scrum effectively
Cost and time savings – Higher levels of employee engagement and motivation lead to reduced turnover and significant cost savings and retention of valuable knowledge. Making the Move from Waterfall to Scrum
The Scrum Framework is simple. Adopting Scrum can be straightforward. To maximize your odds for success, we recommend an approach that has worked well for many other organizations.
The approach works well with the two most common patterns of implementation – Team Level Scrum Adoption and Enterprise Agile Transformation. A summary of the key differences is shown in the diagram below. Both patterns have a number of similarities though an enterprise Agile/Scrum
Transformation is more complex, risky and it takes longer and thus requires additional work and care.
It is best not to underestimate the risk of trying something new, and to provide an environment for experimentation and risk-taking. In the early stages of the transformation, things will seem to be getting worse. Indeed, they may get worse.
This is to be expected and leaders and teams need to be prepared for times that seem chaotic or for teams to be less productive. The Change Process Model is frequently cited to think about major change in systems like organizations. At some point, the performance bottoms out in the ‘trough of despair’. Leaders and teams may be inclined to think the change was a mistake, to actively or passively resist the change, or to talk of ways of returning to the good old days of waterfall development.
Communications about the change curve above should discourage the thinking that Scrum is some sort of silver bullet that is going to make everything better right away. Leaders need to continually re-cast the vision for the change, and the anticipated benefits of changing.
They need to help continually champion the effort and support the teams and the organization through the trough of despair.
The Last Word
We at Projex Academy hope you enjoyed this brief overview to Scrum.
But you already know that the key to implementing Scrum – both for yourself and your organization – is being able to implement these ideas.
And for that, you need not just the ‘what’ and ‘why’ of Scrum – but the ‘How’
