Talk about
your project with us:
The whole business world talks about “agile” – agile projects, agile management, agile services, agile product development. Everything has to be faster, more flexible, cheaper, more meaningful, self-organized and of course customer-centric. Teams become squads, meetings become stand-ups, tasks become user stories, milestones become Minimum Viable Products, off-sites become hackathons, and office walls are full of sticky note boards.
Those who are not agile are not modern. This is exactly why methodological competencies are acquired, techniques are trained, frameworks are introduced and sprints are initiated. But why do many organizations currently dealing with this topic experience such big challenges in establishing agile working methods? After all, it seems that everyone has understood what it is all about and how urgently companies need to become agile in order to stay ahead of their competitors. But first things first.
01 Definition and Meaning of Agility
Agility is the ability to react quickly and at the same time appropriately to a complex and dynamic environment, often to be seen in the form of fast changing customer requirements. Agility therefore means flexibility, or – quite simply: liveliness.
Agile organizations have understood that they are operating in an increasingly complex environment and must be able to quickly adapt to new circumstances. In response, they reflect the dynamics of their environment in their own organization – and in some cases even manage to stimulate the market themselves. Characteristic features of agile organizations are a strong customerfocus, short and iterative planning and development cycles, flat hierarchies and a high degree of self-organization.
Why is agility important?
Many organizations are feeling the pressure of an increasingly dynamic market environment in which it is important to remain competitive:
- Digitalization leads to disruption, which drives existing technologies, products and services out of the market within short time. New players seriously challenge established organizations. When accumulated knowledge and company size do not create a significant and sustainable competitive advantage, the importance of innovation and agility grows enormously.
- The growing number of uncertainties in the market environment inevitably increases the speed at which organizations have to make decisions and adapt to changing conditions. Predictability loses its significance: in the past, projects could be planned and rolled out over several years like a waterfall, whereas today shorter, iterative cycles are usually the way to go – the shorter, the better.
- The perception of one’s own contribution to value creation in the organization is becoming a central driver of employee motivation. External control and insufficient self-efficacy destroy motivation and drastically reduce agility and innovative power.
Talk about
your project with us:
02 Agile Manifesto
In 2001, 17 renowned software developers published the Agile Manifesto (Manifesto for Agile Software Development, Agile Manifesto). Among the first signatories were the two Scrum founders Jeff Sutherland and Ken Schwaber. To date, thousand more signatories have joined, publicly committing themselves to the principles of the manifesto. The authors wanted to bring the core ideas of modern software development to a short, common denominator.
The Agile Manifesto consists of four guiding principles that contrast agile values with traditional approaches. It reflects the spirit of agility and forms the foundation for agile methods like Scrum:
- Individuals and interactions are more important than processes and tools
- A functioning product is more important than a comprehensive documentation
- Responding to change is more important than following and executing a plan
- Collaboration with the customer is more important than contract negotiations
The four guiding principles are further concretized by a total of twelve principles. They explain in more detail the values and principles for agile teams:
- Satisfy the customer through early and continuous delivery of functioning and valuable products
- Welcome changing requirements, even late in development stages
- Deliver working products frequently, from a couple of weeks to a couple of months – the shorter the time span the better
- Business and developers work closely together on a daily basis
- Build projects around motivated individuals and provide them with the necessary environment, support and trust
- Transmit and exchange information through personal communication
- Working products are the primary measure of progress
- Maintain a constant pace
- Continuously strive for technical excellence
- Simplicity is essential
- Teams are self-organized
- Teams reflect and tune their behavior regularly.
03 Our Agile Consulting Portfolio
Agile transformation essentially involves establishing a new organizational culture based on agile values and principles. Without those, any method remains ineffective – no matter how well-proven it is. Our consulting service “Agile Transformation” connects method, values and principles with the culture of an organization. Focusing on adding value, inhibiting patterns of collaboration are identified and deliberately broken. Impediments within the organization are identified and iteratively removed in order to create the framework in which the new values can be lived and collaboration can take place according to agile principles.
Our services in the area of “Agile Project Management” are aimed at organizations whose projects are complex and embedded in a volatile environment. The aim is to quickly and iteratively develop so-called Minimum Viable Products (MVP) based on a solid product vision. These MVPs are directly evaluated for added value. Thus, market efficiency can be achieved, validated and, if necessary, adapted at an early stage. We support organizations in creating a framework for agile project management and help them to make their projects more agile.
Paradoxically, in every agile transformation, leadership plays a key role. Traditional management activities become superfluous or are nowadays covered by the team. New tasks and challenges arise and become a success factor for the transformation. In our consulting service of “Agile Leadership” we accompany executives on their way from “manager” to “organizational developer” and a role model for their own employees. With our change know-how and many years of experience in leadership development, we design this transformation process on a personal level together with the respective manager as well as with the entire management team of the organization.
“OKR” is an agile management method that helps organizations to connect organizational goals with the goals of teams and individual employees through well formulated Objectives and Key Results. We support you in the partial or organization-wide introduction of OKRs. Using our expertise in change management, we make successes measurable and transparent without putting pressure on your employees.
Talk about
your project with us:
04 Agile Transformation
Definition and Meaning of “Agile Transformation”
The term “Agile Transformation” describes the path from a classical organization to an agile organization, i.e. an organization that follows a whole range of agile principles in product development and service delivery in order to survive in the VUCA world. Agile transformation is a change process that is not accomplished overnight. After all, for an organization to be truly agile, it needs much more than just methodological competence and shorter planning cycles. Much more important are the general conditions under which value creation takes place in the organization. Those general conditions determine what behavior is appropriate in which situation, what demands an organization has towards its employees and what the limits are that should not be exceeded.
Why do agile transformations fail?
Often it is precisely these general conditions that become the determining factor of success or fail in agile transformations. Structural elements, such as reporting and approval processes, control and planning mechanisms or internal performance incentives and evaluations can either hinder the agile value creation or make it possible in the first place. They are the biggest lever to systematically break up and re-align the fusion of value creation on the one side and the values and principles of an organization on the other side. In order to understand how this can succeed, a fundamental recognition must be made:
The core of an agile transformation are not methods or frameworks, but first and foremost values and principles that govern collaboration within the organization.
Here is why: each and every one of the well-known, much-advertised agile methods and frameworks was created by strictly applying these values and principles to a specific business case – be it SCRUM for project work, Kanban for the service area, Lean Startup for testing new business ideas. Visualization and estimation techniques and tools like burn-down charts or Planning Poker followed.
Unfortunately, agile transformations too often focus on these methods and techniques rather than on values and principles first. However, any method – no matter how trendy – can only be successfully applied by an organization if it follows the same agile values and principles which the method is based on. If this is not the case, the application will not only remain ineffective, in the worst case it will even cause damage. The values and principles that guide the actions of an organization are, in turn, anchored in the organizational culture, which invisibly determines behavior and guides decisions.
This means that a sustainable agile transformation automatically includes a cultural transformation. Agility does not start with sticky notes, squads, sprints, or hackathons. It begins with values and principles and a critical view on the culture.
Step by Step to a (more) agile Organization
Culture is the memory of the organization. It is their immune system that tries to secure the survival of the organization in the future by replicating what was successful in the past. Culture is reflected in the organization: in processes, organizational charts and rules that have proven to be helpful over time. For a sustainable change in the culture of an organization, it is not enough to proclaim new values and cover the corridors with posters – just as it is of little help when you try – at a concert with low energy – to motivate the audience with the help of a teleprompter. Even if all employees, down to the last critical, is convinced of the effectiveness of agile values and principles, the processes and structures of the organization often seem like a thick layer of clay. Only through targeted challenging of existing processes, decision-making rules, org charts, etc. can the current conditions for collaboration be analyzed in small iterations, changed in a targeted manner, and the flexibility of the organization be increased. Each iteration thus allows to collect new epxerience, which will enter into the cultural memory of the organization and lead to a sustainable change.
1. Detect Patterns
An iteration starts with the question of value creation and where the organization is currently hindering it. So first we observe collaboration in order to recognize critical patterns and identify potential starting points. This can be illustrated with a swing: in order to accelerate or slow down an already swinging child smoothly, you must first observe in which pattern the swing is moving. Only then can you apply a push at the right place and time to strengthen or reduce the swing as desired. In the same way we observe and analyze the existing organization and its patterns as a first step.
Example: The HR department of a customer has two streams of value creation: For one thing, it is responsible for administrative tasks such as contracts, certificates, the onboarding process, etc. Secondly, it has to design individual personnel development measures. Internal customers have repeatedly been dissatisfied with the latter service. We observe that the employees in the HR department are used to bringing decisions of a certain scope to their formal manager. So due to their formal decision-making authority, managers have become a strong second point of reference in the daily work of the employees beside their actual customers.
2. Form a Hypothesis
The next step is to set the identified pattern in relation to value creation and to form a hypothesis about the impact of the organization on this value creation. We are looking for a reason why the work does not succeed as planned.
In our example, we recognize that HR employees design personnel development concepts catering mainly to the managers’ ideas. The focus on the customer fades and the customer value of the concepts suffers. We form the hypothesis that without formal power structures, this part of value creation would take place in a more customer-centric way and thus produce better results.
3. Break Patterns
Based on this hypothesis, we jointly search for a suitable lever to break the observed recurring pattern. This describes an organizational intervention – a kind of experiment that allows new things to be tried out for a pre-defined period of time and gather new experiences. New ways of thinking and beliefs can be changed – with a direct impact on the underlying culture. Targeted irritations of the existing organization are needed to enable sustainable change.
In our example, we irritate the existing organization of the department by almost completely eliminating the influence of the manager for the period of the next HR development design cycle – from the clarification of the order to its completion. We limit reporting, give the team full budget responsibility and let them make all decisions on their own, without any intervention by the manager. The manager’s only task is to create the necessary protective space. We accompany both the team and the manager to avoid that they fall back into old behavioral patterns.
4. Evaluate Results
After the completion of the experiment, the occurred changes are analyzed. Did the lever have the desired effect? What aspects of the experiment do we keep, what needs to be reconsidered or adapted? Could this also be a lever for other areas? Or do we have to test something completely different?
In our example, the experiment worked out well. Despite initial uncertainties, the team evaluates the new process as effective and efficient collaboration where they organize themselves independently and focuse exclusively on the wishes and needs of the customers. The result is a product that inspires customers and delivers real added value.
Important: There are no blueprints. The successful experiment only shows that the identified lever worked in this specific environment with this specific team. Before this can be transferred to other teams and areas, you always need a hypothesis and a new experiment. That being said, already collected experience accelerates the observation process and often increases the accuracy in building the right hypothesis.
With each iteration of “Recognize Patterns – Form a Hypothesis – Break Patterns – Evaluate Results”, the organization takes another important step towards an agile organization. However, the transformation itself will never be complete. As long as the environment of the organization remains dynamic and full of surprises, the organization itself will have to continuously question and reinvent itself. Therefore, our aim is to sow the seeds of an agile organization and to enable our customers to initiate and conduct the described iterations as quickly as possible on their own. This way, value creation can be sustainably and successfully organized.
Our consulting approach: More agility through networking and institutionalization
Typically, our consulting projects start in a specific area of an organization. The best conditions for making a business division more agile are given when the assignment and motivation for the change comes directly from divisional management. With coaching and operational support, we empower the divisional managers to effectively build an agile organization from the inside out and to implement cultural changes in a sustainable manner. In addition, we have extensive know-how in identifying value creation levers and enable managers to independently drive cultural changes step by step.
How can a division-related, agile transformation – in our example in the HR department – be transformed into a comprehensive agile transformation that changes the core of the entire organization? The more seeds of an agile organization are sown in the organization and connected with each other, the more experiences can be shared, lessons learned can be exchanged, and common patterns – desired or undesired – can be recognized. With many years of experience in sustainable change management, we have the necessary competence to foster helpful dynamics and to create a self-reinforcing effect.
Many single agile transformations and the open exchange about them gradually disclose the “hidden rules” and “organizational patterns” of the organization and institutionalize the agile organization. In this process, the culture of the company is not turned upside down. Experience shows that many “hidden rules” and “organizational patterns” remain stable, while only those rules and organizational structures that are impediments of change and value creation are replaced in a targeted manner.
Agile transformation should never become an end in itself. First and foremost, there has to be asked the question of value creation and which structures and general conditions currently hinder it. Real value creation is therefore our top priority in every project. In the end, what counts is not how many sticky notes are stuck to your (virtual) office wall and how many sprints you have run, but whether your customer pays for the product or service your organization delivers. We are convinced that well-organized value creation that satisfies real customer needs not only brings sustainable economic success, but also provides employees with a feeling of satisfaction, makes them proud and inspires them. That’s what we stand for.
This is precisely why we do not have a blueprint for “the agile organization”. What we offer you instead is a proven approach to how an agile transformation can be triggered successfully. Our experiences are extremely positive. Whether as a coach, consultant, trainer, co-thinker or co-pilot: Together we find out what your organization needs and have plenty of tools for it.
Talk about
your project with us:
05 Scrum as an Example for agile Methods
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 |
06 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 Scrum’s success and its usage.
Scrum is
- lightweight
- simple to understand
- difficult to master
Roles
- Product Owner – “The Shaper”
- Scrum Master – “The Facilitator”
- Development Team – “The Creators”
Artefacts
- 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
Events
- 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 Theory
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:
TRANSPARENCY 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.
ADAPTION 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.
INSPECTION 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.
Scrum Values
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.
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.
Scrum Process
Scrum Roles & Responsibilities
Product Owner
… 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.
Product Backlog
- 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
Sprint Planning
- Discussing the objectives that the Sprint should achieve with the Scrum Team
- Helping to clarify the selected Product Backlog Items and make trade-offs
Sprint Review
- 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
Scrum Master
… 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.
Sprint Planning
↓
Daily Scrum
↓
Sprint Review
↓
Sprint Retrospective
- 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
Product Owner
- 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
Development Team
- 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
Organization
- 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
Development Team
- 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
Sprint Planning
- 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
Daily Scrum
- 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
Sprint Review
- Demonstrating the work to Product Owner and Stakeholders and answering the questions about the Increment
- Discussing good points, identified problems and problems’ solutions
Stakeholders
(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.
Customer
- 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)
End-User
- 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
Manager
- Providing resources and guidelines within the organization
- Solving problems which the Scrum Master escalates
- Being the last instance to decide upon issues
Scrum Artefacts
Product Vision
Die Produktvision ist ein kurzes Statement, das die Ziele und den Nutzen des Produkts beschreibt.
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”
WHO “needs”
THE “product name”
IS A “product category”
THAT “product benefit / reason to buy”
UNLIKE “competitors”
OUR PRODUCT “differentiation/ value proposition”
Elevator Pitch
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.
Product Increment
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
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
Backlog Prioritization
User Stories are prioritized by the Product Owner according to importance, effort vs. value.
User Stories
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
I ndependent
N egotiable
V aluable
E stimable
S mall
T estable
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
Example:
- All tasks completed
- All acceptance criteria passed
- Code complete
- Fully tested
- No known defects
- Documentation updated
Acceptance Criteria
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
Example:
- “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
Planning Poker
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
Sprint Backlog
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
Tasks
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
Task Board
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
Scrum Events
Sprint Planning
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?”
Backlog Refinement
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.
Sprint Review
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.
Sprint Retrospective
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
Pitfalls
Product Owner function not well defined or lived
Symptoms
- Stories are frequently not done
- Product Owner is not available to answer questions by the team
- Team gets different messages from different sources
Proposed action
- 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
Symptoms
- Sprint Planning meeting takes very long to complete
- Stories are difficult to estimate
- Stories are not finished at the end of a Sprint
Proposed action
- 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
Symptoms
- 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
Proposed action
- 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
Symptoms
- 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
Proposed action
- 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
Symptoms
- 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
Proposed action
- 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
Symptoms
- 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
Proposed action
- 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
07 Glossary
BURN-DOWN CHART
A chart showing the evolution of remaining effort against time. Burn-down charts are an optional implementation within Scrum to make progress transparent.
BURN-UP CHART
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 SCRUM
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.
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.
EMERGENCE
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.
EMPIRICISM
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
and adaptation.
FORECAST (of functionality)
The selection of items from the Product Backlog a Development Team deems feasible for implementation
in a Sprint.
INCREMENT
A piece of working software that adds to previously createdIncrements, where the sum of all Increments – as a whole – form a product.
PRODUCT BACKLOG
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.
PRODUCT OWNER
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).
READY
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.
SCRUM
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.
SCRUM GUIDE™
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.
SCRUM MASTER
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.
SCRUM TEAM
A self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
SCRUM VALUES
A set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
SELF-ORGANIZATION
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.
SPRINT
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.
SPRINT BACKLOG
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.
SPRINT GOAL
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.
SPRINT PLANNING
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.
SPRINT RETROSPECTIVE
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.
SPRINT REVIEW
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.
STAKEHOLDER
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.
VALUES
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.
VELOCITY
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.
- sollte immer genügend Anforderungen (oft in Form von User Stories) enthalten, um mindestens einen, besser zwei, Sprints abzudecken.
- ist ein lebendes Artefakt, es ist erlaubt, dass er wächst und sich verändert, wenn mehr über das Produkt und seine Kunden erfahren wird.
- ist dynamisch; er ändert sich ständig, wenn neue Gegebenheiten eintreten (z.B. neue Anforderungen, Änderungen von Markttrends).
- listet alle Features, Funktionen, Anforderungen, Erweiterungen und Korrekturen auf, die vorzunehmende Änderungen an dem Produkt in zukünftigen Releases darstellen.
Backlog-Priorisierung
User Stories werden vom Product Owner nach Wichtigkeit, Aufwand und Wert priorisiert.
Talk about
your project with us: