Please enable JavaScript.
Coggle requires JavaScript to display documents.
SCRUM, Sprint
heartbeat of Scrum
ideas are turned into value
fixed…
SCRUM
NEXUS GUIDE
Nexus Definition
- framework for developing and sustaining scaled
product delivery initiatives
- builts upon Scrum [scaled Scrum is still Scrum]
- a group of approximately three to nine Scrum Teams that work together to deliver a single product
- has a single Product Owner who
manages a single Product Backlog
- minimally extends the Scrum framework only where
absolutely necessary to enable multiple teams to work from a single Product Backlog to build an
Integrated Increment that meets a goal
- the goal of Nexus is to scale the value that a group of Scrum Teams, working on a single
product, is able to deliver
- by reducing the complexity that those teams encounter as they collaborate to deliver an integrated, valuable, useful product Increment at least once every Sprint
Common scaling challenges solved by Nexus
- reducing cross-team dependencies
- preserving team self-management and transparency
- ensuring accountability
Nexus helps to make transparent and remove dependencies related to
- Process
- Product structure
- Communication structure
Scaling value delivered does not always require adding more people due to dependencies and increase of complexity.
Scaling-down can be important in delivering more value.
Nexus extends Scrum by:Accountabilities
- Scrum Teams working together toward Product Goal
- Nexus Integration Team - NIT
[PO, SM, Nexus Integration Team Members]
- focal point on integration
- based on bottom-up intelligence
- work in NIT takes precedence over individual Scrum Team membership.
Events
- Nexus Sprint that equals Sprint in Scrum
- Cross-Team Refinement [of Product Backlog] - work distribution, dependencies; ongoing process
- Naxus Sprint Planning
- Nexus Daily Scrum [integration!]
- Nexus Sprint Review [replaces individual Sprint Reviews]
- Nexus Sprint Retrospective
Artifacts
- [Single!]Product Backlog -> Product Goal
- Nexus Sprint Backlog ->Nexus Sprint Goal
- Integrated Increment -> Definition of Done
KANBAN GUIDE
Kanban Definition
- strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system
- Flow is the movement of value throughout the product development system
- Kanban optimizes flow by improving the overall
efficiency, effectiveness, and predictability of a process
Basic Metrics of Flow
- Work In progress [WIP] -number of work items started but not finished
- Cycle Time - mount of elapsed time between when a work item starts and when a work item finishes
- Work Item Age - mount of time between when a work item started and the current time [only applies to items in progress]
- Throughput - number of work items finished per unit of time.
Little's Law - for a given process with a given throughput, the more things that you work on at any given time (on average), the longer it is going to take to finish those things (on average)
Service Level Expectation [SLE]
- forecasts how long it should take a given item to flow from start to finish within the Scrum Team’s Workflow
- is used to find active flow issues and to inspect and adapt in cases of falling below those expectations
- has two parts: a range of elapsed days and a probability
- based on historical cycle, if deos not exist on prediction
Flow-based Scrum events and artifacts
- Sprint - Kanban practices can help Scrum Teams improve flow and create an environment where decisions are made just-in-time throughout the Sprint based on inspection and adaptation.
- Sprint Planning - flow metrics are used to understand Team's capacity for the Sprint
- Daily Scrum - focuses Developers on maintaining consistent flow; takes place around Kanban board
- Sprint Review - inspecting flow metrics enables to better monitor progress towards Product Goal; reviewing Throughput provides additional info that can influence delivery dates
- Sprint Retrospective - flow metrics allow to better define improvements of processes; inspecting and adaptating Definiton of Workflow optimizes flow in the next Sprint
- Increment - Kanban helps manage the flow of feedback loops more explicitly and allows Scrum Team to identify bottlenecks, costrains and impediments to enable this faster, more continous delivery of value
Kanban Practices
- Visualization of workflow
- Limiting Work In Progress [WIP] - pull system
- Active management of work items in progress
- Inspecting and adapting the team's Definition of Workflow
Plan-Do-Check-Act Cycle vs. Scrum Feedback Loop
SCRUM GUIDE
SCRUM TEAM
Developers
Commited to creating any aspect of a usable Increment each sprintAccountable for:
- creating a plan for the Sprint, the Sprint Backlog
- instilling quality by adhering to a Definition of Done
- adapting their plan each day toward the Sprint Goal
- holding each other accountable as professionals
Product Owner
Accountable for:
- maximizing the value of the product resulting from Team's work
- effective Product Backlog management including:
- developing and explicitly communicating the Product Goal
- creating and clearly communicating Product Backlog items
- ordering Product Backlog items
- ensuring that Product Backlog is transparent, visible and understood
Scrum Master
Accountable for:
- establishing Scrum as defined in Scrum Guide
- Team's effectiveness by improving practices within Scrum framework
Serves Product Owner by:
- helping find techniques for effective Product Goal definition and Product Backlog management
- helping Team understand the need for clear and concise Product Backlog items
- helping establish empirical product planning for a complex environment
- facilitating stakeholder collaboration as requested or needed
Serves the organisation by:
- leading, training and coaching in Scrum adoption
- planning and advising Scrum implementations
- helping employees and stakeholders understand and enact an empirical approach for complex work
- removing barriers between stakeholders and Scrum Teams
SCRUM EVENTS
- purpose: to enable transparency required
- to create regularity, minimize need for other meetings
- the same time and place to reduce complexity
Sprint Planning
- initiates the Sprint
- is the resulting plan created collaboratively by Scrum Team
- containes the work to be performed for the Sprint
- Product Owner ensures that attendees are prepared to discuss:
the most important Product Backlog items and how they map Sprint Goal
- Team may invite other people to provide advice
- Timebox: 8 hours for one month Sprint
Topics:
- Why is this Sprint valuabale?
Outcome: Sprint Goal at the end of event.
- What can be Done this Sprint?
Outcome: How much work can be completed during the Sprint
- How will the chosen work get Done?
Outcome: work plan necessary to create an Incement that meets Definition of Done
Daily Scrum
- purpose: to inspect progress towards Product Goal and adapt Sprint backlog as necessary, adjusting upcoming planned work
- obligatory for Developers
- to reduce complexity held the same time and place every working day of the Sprint
- if Product Owner or Scrum Master are actively working on items in the Sprint backlog, they participate as Developers
- outcome: actionable plan for the next day of work
- creates focus and self-management
- improves communications, identify impediments, promote quick decision-maiking, eliminate need for other meeteings
- Timebox: 15 minutes
Sprint Review
- purpose: to inspect the outcome of the Sprint and determine future adaptations
- Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed
- Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment
- attendees collaborate on what to do next
- Product Backlog may also be adjusted to meet new opportunities
- Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation
- Timebox: 4 hours for one month Sprint
Sprint Retrospective
- cocludes the Sprint
- purpose: plan ways to increase quality and effectiveness
- Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done
- Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved
- Scrum Team identifies the most helpful changes to improve its effectiveness to be addressed ASAP. They may be added to next Sprint backlog
- Timebox: 3 hours for one month Sprint
-
SCRUM ARTIFACTS
Product Backlog
- emergent, ordered list of what is needed to improve the product
- items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event
- Product backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items
- is an ongoing activity to add details, such as a description, order, and size
Commitment: Product Goal
- describes a future state of the product which can serve as a target for the Scrum Team to plan against
- is in the Product Backlog
- the rest of the Product Backlog emerges to define “what” will fulfill the Product Goal
- is the long-term objective for the Scrum Team
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Sprint Backlog
- is composed of the Sprint Goal (why)
- is the set of items selected for the Sprint (what)
- an actionable plan for delivering the Increment (how)
- is a plan by and for the Developers
- real-time picture of the work that the Developers plan to accomplish during the Sprint
- should have enough detail that they can inspect their progress in the Daily Scrum
Commitment: Sprint Goal
- is the single objective for the Sprint
- is a commitment by the Developers
- provides flexibility in terms of the exact work needed to achieve it
- creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives
- is created during the Sprint Planning event and then added to the Sprint Backlog
- is constantly kept in mind by Developers during the Sprint
If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal
Increment
- is a concrete stepping stone toward the Product Goal
- is additive to all prior Increments and thoroughly verified
- all Increments work together
- in order to provide value, the Increment must be usable
- multiple Increments may be created within a Sprint
- sum of the Increments is presented at the Sprint Review thus supporting empiricism
- may be delivered to stakeholders prior to the end of the Sprint
- the Sprint Review should never be considered a gate to releasing value
- work cannot be considered part of an Increment unless it meets the Definition of Done
Commitment: Definition of Done
- is a formal description of the state of the Increment when it meets the quality measures required for the product
- creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment
- the moment a Product Backlog item meets the Definition of Done, an Increment is born
- if a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review
- if the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum
- if it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
Scrum DefinitionScrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.In a nutshell, Scrum requires a Scrum Master to foster an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- Repeat
SCRUM VALUES
- Commitment
- Focus
- Openness
- Respect
- Courage
EPIRICISM PILLARS
- Transparency
- Inspection
- Adaption
-
Sprint
- heartbeat of Scrum
- ideas are turned into value
- fixed length creates consistency
- new Sprint starts immediately
after conclusion of previous Sprint
- each Sprint can be considered a short project
During Sprint:
- no changes are made that would endanger the Sprint Goal
- quality does not decrease
- Product Backlog is refined as needed
- scope may be clarified and renegotiated with the Product Owner as more is learned
Tools to forecast progress:
- burn-downs
- burn-ups
- cumulative flows
These cannot replace empiricism
Cancellation of Sprint can be done only by Product Owner if the Sprint Goal becomes obsolete.
-
-
-