Agile & Scrum is the answer to the growing pace of change that companies need to address. In many projects, deviations from the plan are the rule rather than the exception. In traditional project management, a change in requirements almost inevitably leads to higher costs and a longer project timeline. In agile project management, such changes are undertaken right from the start. We support companies to transform their projects into more agile step by step. An agile organization is not just about executing projects according to Scrum. It requires a suitable corporate culture. The management, the executives, the processes and the organizational structures must follow an agile spirit and mindset also outside of agile projects.
Agile & Scrum Basics
Agile or not?
|Traditional Projects||Agile Projects|
|Requirements are well known, not many changes expected, changes have to follow a defined process||Requirement||Requirements emerge gradually, constant feedback cycles, approach allows changes frequently in each iteration|
|Experts, clear roles and responsibilities, structured decision mandates and reporting line||Team||Self-organized, empowered employees, cross-functional, end-to-end responsibility, small team size|
|Planned and stage-gated development||Development||Incremental and iterative development|
|Provide one complete solution with a full release (longer release times)||Time to Market||Quick and frequent releases to provide functional modules with each iteration|
|Varies depending on project phase, highly required at the beginning and end||Customer Availability||High – continuous participation and feedback is required|
- Individuals and interactions over processes and tools
- Working product over comprehensive documentation
- Responding to change over following a plan
- Customer collaboration over contract negotiation
- Satisfy the customer through early and continuous delivery.
- Welcome changing requirements, even in late development stages.
- Deliver working products frequently.
- Business and IT closely collaborate on a daily basis.
- Build project around motivated individuals.
- Convey information via face-to-face communication.
- Working products are the primary measure of progress.
- Maintain a constant pace.
- Give continuous attention to technical excellence.
- Simplicity is essential.
- Teams are self-organized.
- Teams retrospect and tune behavior accordingly.
Scrum according to Scrum Guide™
The following information is based on the Scrum Guide™ enriched with hands-on experience from CPC practitioners.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework has a specific purpose and is essential to Scum’s success and its usage.
- simple to understand
- difficult to master
- Product Owner – "The Shaper"
- Scrum Master – "The Facilitator"
- Development Team – "The Creators"
- Produkt Backlog – All features of the target product
- Sprint Backlog – All product features to be created during the Sprint
- Increment – Potentially releasable piece of product
- Definition of Done – When the product is ready for use
- Sprint Planning – Prioritize and define the features to be created in the Sprint
- Daily Scrum – Update your team members on your progress continuously
- Sprint Review – Present your Sprint’s working results
- Sprint Retrospective – Review your team’s working style
SCRUM is more of a framework than a process or technique and is the most popular of the many agile methods. People can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum employs an iterative, incremental approach to optimize predictability and control risk. It is founded on empirical process control theory (empiricism) – knowledge is based on experience and decisions are made based on what is known.
The three Pillars of SCRUM:
Everything about the project is visible to everyone. All involved persons really see and understand what is happening during a Sprint and can predict what will happen in the next Sprint. Increased communication and mutual trust help the team to collectively collaborate for the common goal.
Based on the results of inspections, all project variables are adapted to continuous improvement. An adjustment must be made as soon as possible to minimize further deviation and to ultimately maximize the business value of the product.
All Scrum Team members must frequently inspect all project variables such as processes, techniques, product, team setting etc. to detect undesirable variances from the Sprint Goal.
Courage is a quality of spirit that enables you to face danger or pain without showing fear. It takes courage to call out problems, identify impediments, ask for help, receive help and offer help.
Openness is characterized by an attitude of accessibility without concealment or being secretive. Everyone should know everything about the work during a Scrum implementation.
Respect denotes both a positive attitude towards a person or other entity, and an authentic behavior according to this esteem. Without respect, there would be high potential of miscommunication, low communication frequency and hurt feelings.
Focus is the concentration of attention. People who are not focused are not paying attention in any meaningful way, and can’t learn to any meaningful level of depth.
Commitment is the act of binding yourself to a course of action. If people can’t commit, people will be in the state of doing-nothing limbo, a state of inaction.
Scrum Roles & Responsibilities
... is responsible to align with different Stakeholders. The entire organization must respect his decisions.
... should have full decision-making authority to reduce risk of unnecessary delays.
... is the only person who gives requirements to the Development Team
... is the only person who has the authority to cancel the Sprint.
... could delegate the Product Backlog management job to the Development Team, while he/ she remains accountable.
- Sole person for creating, maintaining and clearly describing the Product Backlog
- Prioritizing the Product Backlog Items
- Ensuring that the Product Backlog is transparent and visible
- Ensuring the Development Team‘s proper understanding of the Product Backlog Items
- Discussing the objectives that the Sprint should achieve with the Scrum Team
- Helping to clarify the selected Product Backlog Items and make trade-offs
- Inviting the Scrum Team to the Sprint Review meeting
- Explaining “Done”/ “Not Done” on the Product Backlog
- Reviewing timeline, budget, potential capabilities, market for the next anticipated release of the product
... is a servant-leader for the Scrum Team.
... is responsible for removing impediments to the Development Team’s progress.
... should work with Scrum Team and the organization to increase the transparency.
- Facilitating the Scrum process
- Ensuring that the Scrum events are held and the team understands the purpose
- Coaching the Scrum Team to follow the rules
- Collaborating with other Scrum Team members to understand the execution of the Sprint and reviewing the Sprint‘s performance and progress
- Finding techniques for Product Backlog management
- Helping the Scrum Team to understand the need for clear and concise Product Backlog Items
- Understand product planning in an empirical environment
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
- Understanding and practising agility
- Facilitating Scrum events as requested or needed
- Coaching team in self-organization and cross-functionality
- Helping Team to create high-value products
- Removing impediments to the Team’s progress
- Facilitating Scrum events as requested or needed
- Coaching the Team in organizational environments in which Scrum is not yet fully adopted and understood
- Leading and coaching the organization in its Scrum adoption
- Planning Scrum implementations within the organization
- Helping employees and Stakeholders to understand and enact Scrum and product development
- Causing change that increases the productivity of the Scrum TeamWorking with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
- The Product Backlog is the only set of requirements for action.
- It should work in a self-organized and cross-functional manner.
- The team decides autonomously about the workload of the next Sprint and the estimated effort for each task.
- There is no title rather than developer in the team; and there is no sub-team. However individual team members may have specialized skills.
- The counts for team members should range from 3 to 9.
- Defining the tasks of the Sprint Backlog
- Making decisions on how to turn the Sprint Goal and Sprint Backlog into a “Done” Product Increment
- Self-organizing to do the work in the Sprint Backlog
- Being responsible of conducting the Daily Scrum
- Inspecting progress towards Sprint Goal
- Meeting after the Daily Scrum for detailed discussions, to adapt/ re-plan the rest of the Sprint’s work
- Demonstrating the work to Product Owner and Stakeholders and answering the questions about the Increment
- Discussing good points, identified problems and problems’ solutions
(According to the Scrum Guide™ not an official Scrum Role)
Due to the individual character of each project there may be wide variances regarding the importance and impact of Stakeholders. Most probably there are even more Stakeholders than those described here. Therefore, a detailed Stakeholder analysis at the beginning and throughout the project is crucial for it‘s success.
- Internal: Individuals/ groups who make the funding decision for the product development effort (typically executive managers or budget managers)
- External: Individuals/ groups/ organizations who pay to use the product (only applies to externally sold product)
- Being the main source of information when defining the requirements
- Being the protagonist in most of the User Stories; reviewing the Increments (passive, based on User Stories)
- Using the finished product
- Providing resources and guidelines within the organization
- Solving problems which the Scrum Master escalates
- Being the last instance to decide upon issues
The Product Vision is a short statement which describes the objectives and benefits of the product
- The Product Vision explains how your product supports the company’s or organization’s goals and strategies
- The Product Vision refers to key product goals, the customer, how to address his needs and should emphasize the unique value
- The Product Vision should be created before the Product Backlog
- It is owned and updated by the Product Owner
Template to create a Vision Statement (by Geoffrey A. Moore)
There are a number of topics that always should be considered in a proper Vision Statement:
FOR "target customer"
THE "product name"
IS A "product category"
THAT "product benefit / reason to buy"
OUR PRODUCT "differentiation/ value proposition"
The classic way to validate the Product Vision is to answer the elevator test: “Can you explain your product in the time it takes to ride up in an elevator?” Passing this test ensures that your Product Vision is clear, engaging and brief.
The sum of all Product Backlog items completed during a Sprint and all previous Sprints.
- At the end of each Sprint, the new Increment must be “Done”, which means it must be in a usable condition and must meet the Scrum Team’s Definition of Done
- If the Development Team has planned and estimated well, the Product Increment includes all Items which were planned in the Sprint Backlog
Product Backlog is a prioritized feature list, containing short descriptions of all
functionality desired in the product.
- The Product Backlog should always contain enough requirements (often in form of User Stories) to cover at least the one, better two, Sprints
- It is allowed to grow and change as more is learned about the product and its customers
- The Product Backlog is dynamic; it constantly changes when new circumstances arise (e.g. new demands, changes of market trends)
- The Product Backlog lists all features, functions, requirements, enhancements and fixes that constitute the changes to be made to the product in future releases
User Stories are prioritized by the Product Owner according to importance, effort vs. value.
User Stories are short, simple descriptions of the desired functionality.
- User Stories are written from the perspective of the person who benefits from implementing the User Story
- The User Story is developed in the format of:
“As [WHO], I want [WHAT] so that [REASON]”
Characteristics of a good User Story
Definition of Done
An agreed list of activities necessary to get a product Increment to a final state at the end of the Sprint.
- The Definition of Done (DoD) is unique per team and is used to decide when a User Story from the Sprint Backlog is completed
- Every Scrum Team has its own DoD. What matters is that each team has a shared definition that everyone understands
- All tasks completed
- All acceptance criteria passed
- Code complete
- Fully tested
- No known defects
- Documentation updated
A list of requirements that have to be fulfilled in order to consider the User Story as complete.
- Created by the Product Owner, the Acceptance Criteria define the boundaries of a User Story and determine when a User Story is implemented
- While the DoD is generic and applicable to all User Stories, the Acceptance Criteria are different for each User Story
- “Home button is visible on all pages.”
- “Clicking home button returns the user to the homepage.”
- “Home button is recognizable.”
Story Points/ Size
Unit of measure for expressing an estimate of the overall effort of a Product Backlog item.
- The Scrum Team estimates the effort to implement the story including everything that can affect the effort (amount of work to do/ work’s complexity/ any risk or uncertainty in doing the work)
- Instead of story points, User Stories can also be sized in other units, e.g. t-shirt sizes S/M/L/XL
Common agile estimating and planning technique which is used to estimate effort or relative size of Backlog items
In Planning Poker, members of the group make estimates by playing numbered cards with values that represent the number of Story Points (0, 1, 2, 3, 5, 8, 13, 20, 40 and 100).
The following rules apply to the game:
- The Product Owner or customer reads a User Story or describes a feature to the team
- The team discusses the feature and asks questions, which the Product Owner has to answer
- After the discussion each team member puts a card face down representing their estimate for the story
- All cards are revealed at the same time
- If all team members have the same value, it becomes the estimate for the User Story
- If not, team members with high estimates and low estimates are given the opportunity to justify their estimate and then the discussion continues
- The estimation process is repeated until a consensus is reached
A list of tasks identified by the Development Team to be completed during the upcoming Sprint.
- During the Sprint Planning meeting, the team selects a number of Product Backlog Items (User Stories)
- The chosen Product Backlog Items are summed up in the Sprint Goal
- The team identifies the tasks necessary to complete each User Story
- During the Scrum cycle, the predefined tasks are completed
- The Sprint Backlog is expected to be updated on daily basis
The breakdown of Product Backlog items into tasks helps the Development Team to plan the next Sprints’ To Dos.
- Ideally, a task is sized in a way that it can be finished until the next Scrum meeting
- For each task, clear responsibilities are defined
- In contrast to User Stories the tasks are defined by the people who do the work – the Development Team
- Tasks can be broken down into smaller pieces if necessary
Work and workflow visualization tool that enables the Team to optimize the flow of their work.
- Work items are visualized to give participants a view of progress and process, from task definition (Sprint Backlog) to customer delivery (Done)
- Team members „pull“ work as capacity permits, rather than work being „pushed“ into the process when requested
- The Task Board should be updated in the Daily Scrums
Sprint Down Burn Chart
Common Scrum Sprint tracking mechanism used to track implementation progress of agile projects.
- The hours to finish each task are estimated by the team at the Sprint Planning meeting
- The Scrum Master calculates and graphs the outstanding work and compares it to the estimation
- The outstanding work (or Backlog) is often on the vertical axis, with time along the horizontal
- Besides planning and tracking the chart also serves as risk mitigation and communication tool
A meeting during which the Development Team commits to the User Stories done in the following Sprint.
During the Sprint Planning meeting,
- the Product Owner describes and explains the highest priority features to the team (work for two Sprints)
- the Development Team decides how many items from the Product Backlog can be realized in the upcoming Sprint based on their capacities
- the Development Team asks sufficient questions that they can turn a high-level User Story of the Product Backlog into the more detailed tasks of the Sprint Backlog
There are two defined Artifacts that result from a Sprint Planning meeting:
- Sprint Goal: a short description of what the Scrum Team plans to achieve during a Sprint
- Sprint Backlog: set of Product Backlog Items and corresponding tasks to be implemented within the next Sprint.
Daily Scrum Meeting
The Development Team meets shortly every day to synchronize activities and to plan the next 24 hours.
15-minutes time-boxed event; Development Team only. Should be held at the same time and place each day, ideally in the morning. The team is inspecting the progress towards the Sprint Goal by asking:
- “What did I do yesterday that helped the team meet the Sprint Goal?”
- “What will I do today to help the team meet the Sprint Goal?”
- “Do I see any impediments that prevent us from meeting the Sprint Goal?”
Helps to prepare and update the Product Backlog for the next Sprint Planning Meeting.
The Backlog Refinement meeting should be held during each Sprint. The target is to update the Product Backlog and get User Stories ready for the next Sprint Planning meeting by:
- Adding or Removing User Stories
- Detailing User Stories
- Defining Acceptance Criteria and Story Size
- Updating priorities of User Stories
The Backlog Refinement helps to prepare the User Stories in a way that the next Sprint Planning meeting starts immediately with clear and well-defined items.
The Development Team demonstrates what they accomplished during the Sprint and the project is assessed against the Sprint Goal.
- Only those results that are a “potentially deliverable Product Increment” are presented, e.g. a coded, tested and usable piece of software.
- Besides the Scrum Team also the Stakeholders should participate in this rather informal meeting.
- The Stakeholders can provide the Development Team with immediate feedback which will be added as a new User Story to the Product Backlog.
The meeting allows the Scrum Team to continuously evolve and improve throughout the life of the project.
Every Scrum Team member should get the chance to air their opinion in an open, honest and constructive atmosphere.
The Scrum Team should
- Inspect how the last Sprint went with regards to people, relationships, processes and tools
- Identify and order the major items that went well
- Find potential improvements and create a plan for implementing them
Product Owner function not well defined or lived
- Stories are frequently not done
- Product Owner is not available to answer questions by the team
- Team gets different messages from different sources
- Each team should have its own Product Owner
- All Backlog Items and work should be communicated to the team through the Product Owner only
- Product Owner should set up regular communication with Stakeholders to align on Product Backlog and priorities
Team is not investing enough time to refine backlog
- Sprint Planning meeting takes very long to complete
- Stories are difficult to estimate
- Stories are not finished at the end of a Sprint
- Scrum Master should coordinate regular Refinement meetings to discuss on upcoming User Stories
- Product Owner should clarify with Stakeholders before planning
- Product Owner should attend Refinement meetings to explain and clarify together with the team on upcoming work
Stories are not broken down enough or not independent
- User Stories are not finished at the end of a Sprint
- Actual effort is often much higher than estimated
- It is difficult for team to act on stories immediately
- Rule of thumb to apply when writing User Stories: A User Story should not take longer than 1/2 or (ideally 1/3) of the overall Sprint duration
- User Stories should follow INVEST (independent, negotiable, valuable, estimable, small, testable)
Team over-commits/ is driven by somebody else
- Stories are not finished or even started at the end of the Sprint
- Team is working at an unsustainable pace to try to complete each Sprint and feels a lot of pressure
- Team should start to track their progress (e.g. how many story points can be completed in a Sprint) to identify an average velocity
- Only the team estimates the work and commits to how much work/ how many stories can be completed during a Sprint
- Align with management and Stakeholders on expectations for self-organized teams
Team is working individually on the Backlog
- Team thinks that each Backlog Item is done only by one person
- Bottlenecks are created around a single team member
- One person or group is working long hours to keep up with demand on their time
- Encourage collaboration on stories to increase the quality of the end product
- Product Owner should write stories that provide the opportunities to pair
- Cross-train the team on skills, subject matter experts work with one or two team members to enable them to gain new skills
Additional work is interrupting the Sprint
- Team discovers significant unplanned work or receives requests from Stakeholders that must be done right away
- Planned stories don’t move to ‘Done’
- Team feels that priorities are constantly shifting
- Include Sprint buffer for ‘additional/ found work’
- Use retrospectives to identify ways to anticipate additional work better
- Confront leadership with the effect of interruptions
- Encourage the Product Owner in his/her role and defend the team from interruptions
A chart showing the evolution of remaining effort against time. Burn-down charts are an optional implementation within Scrum to make progress transparent.
A chart showing the evolution of an increase in a measure against time. Burn-up charts are an optional implementation within Scrum to make progress transparent.
Daily time-boxed event of max. 15 min. for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.
DEFINITION OF DONE
A shared understanding of expectations that software must live up to in order to be releasable into production. Managed by the Development Team.
The role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Product Increment every Sprint.
The process of the coming into existence or prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.
Process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection
FORECAST (of functionality)
The selection of items from the Product Backlog a Development Team deems feasible for implementation
in a Sprint.
A piece of working software that adds to previously createdIncrements, where the sum of all Increments – as a whole – form a product.
An ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
PRODUCT BACKLOG REFINEMENT
The activity in a Sprint through which the Product Owner and the Development Team add granularity to the Product Backlog.
The role in Scrum accountable for maximizing the value of aproduct, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).
A shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog Items introduced at Sprint Planning.
A framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated Roles, Events, Artifacts, and Rules, as defined in the Scrum Guide™.
SCRUM BOARD (TASK BOARD)
A physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum Boards are an optional implementation within Scrum to make information visible.
The definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. This definition consists of Scrum’s Roles, Events, Artifacts, and the Rules that bind them together.
The role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a properunderstanding and use of Scrum.
A self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
A set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
The management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.
Time-boxed event of 30 days, or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
An overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team.
A short expression of the purpose of a Sprint, often a business problem that is addressed. Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.
Time-boxed event of eight hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint Backlog.
Time-boxed event of three hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.
Time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the Stakeholders to inspect the Product Increment resulting from the Sprint, assess the impact of the work performed on overall progress and update
the Product Backlog in order to maximize the value of the next period.
A person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum Pillars of transparency, inspection, and adaptation come to life and build trust
for everyone. The Scrum Team members learn and explore those values as they work with the Scrum Events, Roles and Artifacts.
An optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.