Software Engineering :: Agile :: Courses :: Scrum Fundamentals
⪼ Made with 💜 by realpolyglot.dev
- by David Starr
- Roles, Artifacts, and Events
- Evidence-based Decision Making
- Tools & Techniques
- You'll be able to lead your organization to genuine agility through scrum
Goal: Replace ACS
- 2001 - Coding Starts
- January 2005 - All code scrapped
- FBI Director Mueller asks congress for more money (Three Times)
- Let's use Agile: Jeff Johnson & Chad Fughram enter in 2010
- Vendors: FBI cancels contract with external vendors
- Staffing: Staff reduced from 400 contractors to 40 FTEs
- Scrum Studio: Created in the Hoover building
- Done: Software completed Dec. 2011 ($30m spent)
- Scrum Origins, Theory, and Value
- Empiricism and Scrum
- Scrum and Certainty
- The Role of Lean Thinking
Pause for one minute to define scrum in your own mind and write down your definition. Take no more than three sentances.
...
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
- Scrum Guides
- Product Backlog - Owned by Product Owner. The set of things that might be applied to the product or the work to be done.
- Sprint - A timebox which contains all of the other events that happen within the sprint. A sprint should be one-month or less, no more than that.
- Sprint Planning Meeting - Has the input of the product backlog and from it, the developers create a sprint backlog.
- Sprint Backlog - A plan for the sprint
- Daily Scrum (standup meeting) - Create a daily plan. A plan for the day should come out of each standup.
- Increment - When done with the sprint, an increment is produced. There is nothing that prevents a team for producing multiple increments per sprint.
- Sprint Review (demo) - Meeting in which anyone interested in the product is welcome to come review and inspect the increment that was created. During sprint review, we ask "What do you think?" and we take the feedback from that question and it will influence the next things to be done according to the product backlog.
- Sprint Retrospective - An opportunity for the scrum team to get together and discuss how to improve both the team and the quality of the product. In doing so, they'll often provide feedback that influences the product backlog. The intent is to produce a plan for improving as a team, as a group, and the quality of the product.
Developed early in the 1990's. Scrum's creators were collaboring on the first scrum project by 1993. They co-announced the official framework in 1995.
- Jeff Sutherland: Leading expert on how the framework has evolved to meet the needs of today's business. He's successfully applied scrum to several other industries including: Finance, Healthcare, Higher Education, & Telecom
- Ken Schwaber: Founded the scrum alliance and the agile alliance. Left the alliance to found scrum.org
- First published in 2010
- Revised in 2020
- The definition of Scrum
- The rules of the game
- Not the strategy for winning
Scrum is rooted in:
- Empiricism: Knowledge comes from experience and making decisions based on what is observed. Almost akin to practicing the scientific method.
- Lean Thinking: A set of rules & philosophy that reduces waste and focuses on essentials of product development.
Engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed
- Founded on teamwork
- Transparency
- Inspection: on the team and product
- Adaptation (proactively)
- Commitment
- Focus
- Openness
- Respect
- Courage
- Because we value commitment, we will turn up on time
- Beacause we value focus, we will not interrupt someone whose status is set to "Do not disturb"
- Because we value openness, we will post decisions that may impact the team
- Because we value respect, we will not chit-chat during the daily scrum meeting
- Because we value courage, we will have necessary difficult converations
- Small teams and large organizations
- Fixed price work
- Non-software development work
- FDA-approved, life critical systems
- ISO 9001 certified applications
- Highly secure financial services systems
- Desired outcomes are known to an exacting standard
- The same input results in the same output every time
- Steps taken by participants are defined before work begins
- Feedback loops inform next steps
- Process steps are less important than the final product
- What will be produced may not be exactly known when work begins
Is needed when these things are true
- We don't know the exact outcomes at the time work begins
- We want to control the results and keep quality high
- Steps aren't always repeatable
Requires these things to succeed
all defined in the scrum framework
- Transparency
- Inspection
- Adaptation
We're going to define the step before we get started
A lot of conversation at the very beginning of a project with the client to understand what they want; we touch base at the mid-point in the project showing what we've created so far; however, we don't have regular conversations with our client as we produce the product.
At the end, we have a lot of discussion with our customers because we are trying at the very end to insert quality into the product and ensure that we've created what the customer wants.
Plan driven says, we're going to define the steps before we get started:
- Plan the work
- Analyze the work to be done
- Start Develop
- After development, we hand off to Test
- Integrating different components of a large product together
- Validate that all of these things took place
- Deploy
New learning drive adaptation of tools, processes, practices, and the scrum team itself. Inspection is performed by the customer regularly, and feedback is collected at regular intervals, ensuring that empiricism is used to guide the immediate future direction of the product.
In scrum we iterate over each of these steps at regular intervals:
Lean think is the philosophy of identifying and removing waste from a system
Scrum has been heavily influenced by lean which has been successfully applied to software development for the last 20 or so years.
The automobile industry in Japan began building on Lean in the 1950's which turned around their companies from producing poorly made and defect-prone vehicles to becoming some of the most reliable on the world market.
Lean manufacturing is a business model that seeks to deliver high-quality products or services as efficiently as possible and efficiency is a huge component of lean thinking. It's grounded in eliminating waste but also in expanding capacity to do work by shortening cycle times and understanding what the customer needs and what is important to them. The Toyota way is a set of principles driven by lean thinking defined by Toyota. Toyota first summed up it's philosophy, values and manufacturing ideals in 2001, and this is what they called the Toyota way.
It consists of principles in two key areas:
- Continuous Improvement
- Respect for people
New united motor manufacturing incorporated (a partnership between Toyota and General Motors)
Applying the five lean principles is a continuous process without end...
Value is anything the customer is willing to pay for
It is important to discover the actual needs of the customer, not just what they want. Customers may not know what they need or are unable to articulate it.
The goal is to use the customer's value as a reference point and identify all of the activities we as a development team need to go through to deliver this value.
Value Stream Map We document every step of a value delivery pipeline; it becomes much easier to identify the waste in a system and eliminate it.
After eliminating waste from the system, we ensure that the flow of the remaining steps runs smoothly without interruption and without delays.
The goal of a pull-based system is to limit inventory and work-in-process; enabling a smooth flow of work. A pull based system enables just-in-time delivery where products are created at the time they are needed and in just the right quantities that are needed.
Make lean thinking and continuous process improvement a part of the organizational culture. Every employee should strive towards perfection while delivering products based on the customer needs. Here the company becomes a learning organization and finds ways to get a little bit better every day.
A means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evoluationary change rather than having some big-bang change all at once.
- Visualize our work in progress
- Limit our work in progress
- Manage Flow through the system
- Make policies explicit; when there's a decision made about how we're going to hand-off from one stage of development to the next, we need to be very clear about what the end state of the hand-off stage is
- Implment feeback loops
- Improve collaboratively, evolve experimentally: we evolve our product and our processes by experimentation
Things are uncertain at the beginning of a sprint and more certain as the sprint progresses. Uncertainty is managed by regular inspection of our work and establishing certainty at regular intervals. This requires frequent and healthy communication with our customers
- Scrum's Origins, Theory, and Value
- Empiricsism
- Scrum and Certainty
- Lean Thinking
The roles scrum defines and their accountabilities
- The Scrum Team: the team consisting of all other roles
- The Product Owner
- Developers
- The Scrum Master
Who is included in the Scrum Team and the expectations of the Team
The members working outside of the scrum team are involved because they want to understand the work and the outputs of the team.
Those outside members can contribute to the success of the scrum team, but are not accountable for the work.
- Smaller teams of 10 or fewer are more effective: empirical study has found that smaller teams are more effecive. Communication is clearer and the work of individuals on the team is more transparent to other team members, thus, more clearly understood. Teams with greater than 10 members tend to self-divide into two working groups, defeating the advantages of having a single team focused on producing a shared product increment.
- Self-managing: means that the team is responsible for their own work, including processes, tools, behaviors and technical practices.
- Always focused on the Product Goal: each product has a specific goal in delivering value to the customers; the scrum team is always focused on delivering that value according to the product goal.
- Cross-functional: the team has the right members to deliver working increments of the software. The team must have all the skills required to do this. The sum of all skills on the team are enough to deliver working increments of the product at very high quality.
One goal of the scrum team is to become a high performance team
This won't happen right away; The team must come together to achieve this over the course of a few sprints...
High Performance Teams Share These Common Characteristics
- Reflect on themselves and their performance
- Consistently produce high-quality results (scrum demands this)
- Are primarily intrinsically motivated
Without the work of the product owner, there's no product to develop
The Product Owner is responsible for ensuring the highest value work is done next. They have an unrelenting focus on delivering the highest possible value with each sprint and they always know what work needs to be done next to deliver that value. That potential value is reflected in the product backlog.
- Establish the Product Goal: take input from people on the scrum team and others outside the team
- Order the Product Backlog: can sometimes delegate this work but the product owner remains accountable for delivering the highest possible value with each sprint
- The Product Owner clearly communicates Product Backlog: responsible for ensuring that everyone who needs to know about the product work is familiar with the product backlog and its contents
- The Product Owner has the final word on Product Backlog order: sets the direction of work to be done by the scrum team.
- The organization must respect their decisions
- Is accountable for their decisions
- Is not a group or committee
- Knows how to represent many stakeholders in the Product Backlog
The Product Backlog items are all well-refined and understood
The work being done in each Sprint is not creating value in the product
- Replace the Product Owner
- Create working product increments: at least 1 increment per spring
- Establish the Sprint Plan -- the Sprint Backlog
- Adapt their work daily to meet the Sprint Goal
- Hold each other accountable, sometimes with difficult conversations
Like the Scrum Team as a whole, the Developers must have all skills needed to deliver high-quality product Increments.
- Generally do not reach outside the team during the sprint for help with delivering increments
- Can be done in collaboration with other; however, this collaboration typically happens when planning the sprint, not during
- Product creators
- Contributing architects
- Site reliability engineers
- DevOps specialists
- Anyone directly contributing to delivering the Increment
- Achieving the Sprint Goal
- Items in the Sprint Backlog
- Improving themselves and the quality of the product
- Anything needed to deliver a working Increment
The Scrum Master has a lot of responsibility and most people don't understand this...
- Scrum Teams
- Developers
- Product Owners
- The Entire Organization
The Scrum Master works across the organization
- Is a Scrum expert
- Teaches and coaches the organization
- Helps everyone understand Scrum
- Creating Increments that meet the Definition of Done
- Cross-functionality and self-management
- Better ways to manage the Product and Sprint Backlogs
- Establish empirical decision-making practices across the organization
- A primary accountability is the effectiveness of the Scrum Team
- The is done through effective teaching, coaching, and leading
- This means removing impediments to the Scrum Teams' success
- Advise on practices complementary to Scrum
- Facilitate stakeholder collaboration
- Ensure all Scrum events are executed effectively and within prescribed timeboxes
- Teaching
- Coaching
- Facilitating
- Mentoring
- Yes
- In establishing Scrum
- By influencing the organization
- By advising on good Scrum practices
- If they have the expertise and capacity
- If they can serve each Scrum Team effectively
- If they can still serve the organization's needs
- Sometimes helps make being a Scrum Master a fulltime job
- Are all Developers expert in all Scrum Master responsibilities?
- Being a Scrum Master is often a fulltime job.
- Scrum Teams
- Product Owners
- Developers
- Scrum Masters
- Product Backlog
- Sprint Backlog
- Increment
- Definition of Done
- Product's future state
- Used to plan
- Long-term focus
- Product Owner's responsibility
The single source of truth for work to be done by the scrum team to improve the product
- Ordered for execution: in terms of value
- Emergent: the product backlog changes as more is learned about reaching the product goal; it's ok not to know all the work that will be exectued initially
- Transparent: available for all appropriate parties to see; including scrum team, stakeholders, and especially, the customer
- Focused: should not contain work that is not in direct support of the product goal and this means things like ad-hoc work desired by outside parties
All of these are valid PBIs (Product Backlog Items)
- Features
- Functions
- Defects
- Requirements
- Enhancements
- Bugs
- Change Requests
- Product Improvements
the product backlog is ordered for execution
- The top is more detailed and understood
- Ordering considers risk, value, effort: considers the needs of the customer
- Changes frequently: as more is learned about how to reach the product goal and provide the most values
- Valuable Items Only: each item is considered by the scrum team before execution of the work begins
- Fit in one sprint: minimum of two product backlog items to fit into one sprint
- Actionable: enough detail to become actionable
Someone wants to add an item to the product backlog, they are passionate about this PBI, but, it will never get worked on
- allow them to add it to the PBI and explain the work that will be executed ahead of this item
- be straight-forward that other priorities will superceed this item and there's no point in adding it at all: this would be wasted work on their part
An executive demands specific work be in the next Sprint; this work will not produce the highest value and does not support the Product Goal; however, she remains adamant.
- Go to the Scrum Master; the Scrum Master should be able to negotiate this delicate situation
- ...
- A Sprint Goal is created to provide a mission statement for the work of the sprint. The Sprint Goal is in support of the Product Goal.
- The set of PBIs are selected for the sprint during sprint planning.
- Provides a plan for the Developers to deliver the increment.
- By and for the developers
- Visible and current
- Changes during the sprint
- What: will be done in the current sprint?
- How: the work will be executed (assess progress)
- Who: the developers
- Why: overall reason to conduct the sprint in the first place
The Sprint Backlog often consists of decomposed Product Backlog items
Your manager wants to add an item to the Sprint Backlog during the Sprint. What do you do?
- Does the item support the Product Goal?
- Does the item support the Sprint Goal?
- Does the Product Owner agree?
- Can it fit within the scope of the current sprint; if not, does the Product Owner agree to trade out an item of equal size?
When trying to create a Sprint Goal, the Developers realize there can be no single Sprint Goal.
- Work is coming to Scrum Team from multiple Product Backlogs
- The Product Owner isn't doing their job well of maintaining a single Product Backlog
- Developers in this scenario must refuse to start the sprint
- Scrum Master in this scenario must coach the Product Owner reset the Product Backlog in a way that developers can pull items from the top of the Product Backlog and establish a Sprint Goal
- Now Sprint Planning can occur
An Increment is the output of a Sprint and is a tangible step toward the Product Goal.
- More than one per Sprint is fine; though, not necessary.
- May be delivered anytime during the Sprint; it doesn't need to wait unti the end.
- Increments are additive to all prior Increments, building on the single product.
- Increments are usable and demonstrable during Sprint Review (demo) and can be used by the customer if needed and requested.
An Increment must have value and is the ultimate expression of value-add to the product.
The Definition of Done describes all things that must be true about an Increment before it may be released.
- Focuses on Improving Quality
- Is Definied by Developers
- Grows over time to increase product and team quality with each Sprint
- Shared across all Scrum Teams that may be working on the same product
An Increment cannot be released or considered done until it meets all criteria of the Definition of Done
There is a Sprint Backlog Item that is NOT completely done by the end of the Sprint
Near the end of the Sprint the Product Owner wants the Sprint Backlog item to be shown at the Sprint Review and realeased.
- Talk to the Scrum Master to help facilitate this discussion and reach an outcome in accordance with Scrum.
- Split the Backlog Item into more than one item in order to show what IS done and put the rest of the work on the Product Backlog for a subsequent Sprint
One feature remains in the Sprint Backlog and it works as expected with no known defects; though, it has not been fully documented, which, is part of the Scrum Team's Definition of Done. Bob assures the team he will finish the documentation right after the Sprint Review meeting.
- Yes
- No: the item is not considered done per the Scrum Team's Definition of Done
- Product Backlogs
- Sprint Goals
- Sprint Backlogs
- Increments
- Definition of Done
Event meeting in Scrum is a planning meeting
- The Sprint
- Sprint Planning
- Teh Daily Scrum
- Sprint Review
- Sprint Retrospective
Events it contains...
- Sprint Planning
- Teh Daily Scrum
- Sprint Review
- Sprint Retrospective
- One month or less
- 2-weeks is common
- A Container: for all other Scrum Events
- Primary Input to the Sprint: The Product Backlog
- Primary Output of the Sprint: The Increment
- Scope may be negotiated between the Product Owner and the Developers
- The Sprint Goal is fixed
- The Product Backlog is refined
- Quality stays high
- Shorten Sprint Length for faster learning cycles (with this, you'll learn more about what the customer values)
- Examine Evidence: Look at evidence seen in prior results as evidence
- Change Direction
The Product Owner wants to discard work currently underway; they want to replace existing work with work not supporting the Sprint Goal.
- Set the Product Owner's realisic expectation and inform them about how Scrum encourages and enables focus or negotate such that the new work still supports the Sprint Goal; and if nothing else works, then, the Product Owner must cancel the sprint and sit down as a Scrum Team and re-plan the work of a new sprint.
- Product Backlog
- Sprint Planning
- Sprint Backlog
- eight hours for a one-month Sprint
- Shorter for shorter Sprints
- Timeboxed means a hard stop
- Doesn't mean, "Use all the time"
- Participants are ready for Product Backlog items
- For the whole Scrum Team
- May invite outside advisors (i.e. visiting architects who are trying to orchestrate work over many Scrum teams)
The more the Developers know about past performance, the Definition of Done, and future capacity, the more accurate their forecasts.
- A full understanding of the Definition of Done
- Data about past performance in order to compare to the forecast of future performance
- A defined amount of capacity that will be available during the sprint: need to know who will and will not be available
The Product Owner only scheduled one hour to plan a three-week Sprint; at the end of that hour, the Scrum Team doesn't have a complete plan; People have meetings to attend and are about to drop off the call.
- The Scrum Master reserves time needed to plan on Scrum Teams calendar in order to complete planning
- The Scrum Master communicates that the work will not begin until planning is complete
- Create Sprint Goal: Collaboration between Developers & Product Owner
- Select PBI
- Can we deliver in this Sprint (No) Skip the PBI (Yes) The work goes into the Sprint Backlog
- Can we take on more work? (Yes) Select PBI (No) Sprint Backlog is complete
The Daily Scrum is more broadly known as a daily standup ... by and for the Developers
- 15-minute timebox
- Same time and same place every day
- Assess progress toward the Sprint Goal
- Adjust the Sprint Backlog as needed in support of the Sprint Goal
- Create a plan for the day that includes all of the developers
- Scrum Master may facilitate; however, once developers are comfortable with the process, they might self-organize and only bring impediments that they can't solve to the Scrum Master after the daily scrum
The Scrum Master facilitates; but, typically doesn't take part.
The Daily Scrum is one place we need to be vulnerable.
- Look Behind: What got done since yesterday's Daily Scrum?
- Look Ahead: What do you plan to do before tomorrow's Daily Scrum?
- Check State: Are there any impediments in your way?
The same two people often talk or whisper during the Daily Scrum. This is disruptive and annoys the Scrum Team members who are there in sincerity to make a plan for the day.
- Quietly remind them to be respectful
- Bring it up to the individuals
- Have the manager step in
- Ask Scrum Master to facilite a discussion
- Scrum Team
- Customer
- Product Backlog
- Outside experts
- Increment
- Product Goal
- Sprint Planning
- Anyone relevant may attend
- Four-hour timebox for 1 month sprint (shorter for shorter sprints, never longer)
- A Working meeting: discuss progress toward the Product Goal; Refine the Product Backlog based on new learning and feedback
- The Scrum Team shows the Increment
- Scrum Team
- Customers
- Key Stakeholders
- Discuss what has changed on team or in product since last Sprint Review
- Collaborate on what to do next and any Product Backlog changes
- Show your work instead of slides
- Get answers to the question: "What do you think?" (looking for honest feedback)
The Goal of a Retrospective: A planning session focused on ways to increase quality and effectiveness
- Whole Scrum Team attends
- Scrum Master typically facilitates
- Timeboxed to 3 hours per one-month Sprint
- Current Sprint Results: Things that happened, were delivered, or not delivered, in this Sprint.
- Scrum Team: The whole Scrum Team needs to attend. No one else.
- Improvement Plan: The team leaves with a plan for improving quality in the product and in the team itself.
- Revised Product Backlog: The Scrum Team may update the Product Backlog.
- Establish a known baseline
- Plan improvements for the next Sprint
- Increase the Definition of Done
- Definition of Done
- Individuals
- Interactions
- Tools
- Processes
The Scrum Master facilitates the Sprint Retrospectives. The same techniques are employed each time. Developers feel the value of the Sprint Retrospective is diminishing.
- Diversify the technique used to facilitate discussion
- Make it a recurring planning meeting
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
- The Sprint Board
- Charting Sprint Progress
- Retrospective Backlog
- The Estimation Wall
- Scrumbut
The Scrum Board is a plan and it should reflect all of the steps in the value stream; what does it take for the team to fully deliver value in the Increment; also, it shows a plan to meet the required Definition of Done, so there's no limit to the number of steps, but each is a queue in the sprint plan, and as a result, work may get bottlenecked in these queues. One way to prevent long queues from forming on the board is to add Work in Progress Limits.
Common Sprint Board
Shows some items that might be part of the Definition of Done
This is a practice borrowed from Lean that seeks to eliminate waste and to do that by having us work on fewer items at one time. This improves focus and enables the team to fully concentrate on what they're doing.
There is more work in that column than the team has agreed should be there.
Someone on the team needs to stop and fix this before we move on and they need to perform the inspection represented by this column whatever the explicit contract of inspection might be.
This fully represents the Sprint Plan and should be visited at least daily, typically during the daily scrum; however, anyone can visit anytime and is managed by the Developers. Items may change as needed.
- Sprint Goal
- Product Backlog Items
- Definition of Done
- Retrospective Commitments
- Burndown Chart
A visual aide for tracking progress toward the Sprint Goal throughout the Sprint
The most common and accessible way to chart a team's progress during a Sprint
- Number of Sprint Backlog Items
- Numbers present in the estimates of work that were assigned during sprint planning or refinement
Team started with 30 items to be done by the end of a two week sprint (10 business days)
The Developers didn't finish everything planned for the Sprint
This is a sign that the Scrum Team didn't negotiate scope during the sprint to meet the realities of the developer's capacity.
Developers got done with the defined work of the sprint ahead of time
- Education
- Automation
Developers have pulled work that takes a solid 2-weeks to complete and the pressure to deliver mounts up toward the end ... in the last week, items are closed at a more rapid rate.
Very rare that a team produces a linear burndown chart.
- Estimation Units Remaining
- Sprint Backlog Items Remaining
- Product Backlog Items Remaining
- Other Work Constructs
Exact Opposite of a Burndown Chart (Better Representative of the Reality of Work To Be Completed)
Perhaps the Product Owner Convinced the Team to Take on More work during the sprint
Visited & Refined each sprint retrospective; Scrum Team works to actively manage the Definition of Done and we select items from the Definition of Done to work on in th next Sprint (commitments). Select 1-2 items at a time so as to not take away from making progress toward the Sprint Goal.
- Items to add to the Definition of Done (Soon or in the future)
- Items that increase communication across the team
- Items that increase focus within the Scrum Team
- Items that help keep focus on the Sprint Goal
- Items that decrease tool friction
Items for improving the Product, Process, or Scrum Team
-
Automate the Build -
Add Unit Tests for new or Revised Code -
Be on-time to all Daily Scrum meetings - Deploy to Integration Test environment
- Estimate PBIs before Sprint Planning
- Create Integration Tests
- Run Integration Tests upon successful build
Might not be shown publicly, but is for the Scrum Team
- Leave things on the wall or board from previous estimation sessions
- To start, a person pulls an item that's ready to be estimated and compares to items already on the wall or board (compare to work that has already been estimated and done)
- They then select a column into which they will place the item
- When its a person's turn, they have two choices, they can (1) pull another item to estimate from the next column (2) they can move an item that's already on the wall or board
- Product Owner prepares the next column before the estimation meeting
- Developers take turns pulling items from the next column
- The Scrum Team considers the item by comparing it to items already on the wall
- Developer places the item on the wall
- Next person (1) Moves an existing card ... or ... (2) Pulls a new PBI
- Repeat
Sprint Retrospectives uncovered oppressive management practices, ... so we ... ignore them to save our jobs
Sprint Retrospectives found that one team member was a bully, so we ... collectively and wordlessly agreed not to confront them
We wanted a quick and easy way ot refine the Product Backlog, so we ... use Planning Poker, and we learned that test driven development improved our overall quality, so we include test-first practices in our Definition of Done.
- The Scrum Board
- Charting Progress for the Sprint
- Retrospective Backlogs
- Estimation Walls
- Scrumbut and Scrum and ...
Practices that complement the framework; Things we can do to augment Scrum in positive and effective ways without modifying the framework and staying true to the empiricism that Scrum is grounded in...
- Estimation
- Velocity
- Defining Done
- Sprint Planning Techniques
- Sprint Retrospective Techniques
Looking at ways agile teams successfully estimate work to help create forecasts.
In the Scrum Guide, the Product Backlog Refinement is defined as an ongoing activity to add details such as size or estimates to the refine the Product Backlog. This happens throughout the Sprint.
Adding order, size, and detail to the PBIs (Product Backlog Items)
- Use estimates and estimation to discuss and discover things about PBIs: When we talk about them enough to be able to estimate them, we get to a point where we understand them at a fundamental level
- This is most effective when we use Quick and Simple techniques
- Shoot for very little discussion, keep moving
- These meetings are not design meetings
- Precision is not the point
- A perfect estimate is wasted effort
A popular agile estimation technique where players estimate the size of work using a card with a number on it and that number typically comes from something like the fibonnaci sequence.
- The Product Owner presents the Product Backlog Items to be discussed.
- The Item is discussed and any additional detail that's needed to understand it gets added to that Product Backlog Item.
- Each estimator selects a card for their estimate and puts it out face-down so nobody else can see it.
- All cards are shown at once to avoid forecasing of estimates; we don't want to know what people are going to estimate before they do.
- Repeat until the discussion causes a convergence in the estimates. People are going to be estimating at different sizes when they first turn their cards over, then we're going to talk about things and hopefully converge on an estimate that we can all agree to.
- Finds the size collaboratively
- Doesn't use time as a unit of measure
- Everyone is heard
- Relatively fast
- Can be fun
- May bog down in technical discussion
- You may need a timer to keep things moving
- When players disagree, an estimate may not be possible
- Can be slow
Works well for very large estimation tasks; when you have a lot things that you have to estimate. This can happen at the beginning of project for example or the beginning of product development.
- The Product Owner reads the first item to the team and places it on a wall or other surface; then asks the question "Is the second item bigger or smaller than the first item". If it's bigger, it's placed to the right of the first item, if it's smaller, it's placed to the left.
- Smaller items are on the left, bigger ones are on the right.
- The team is asked to size the next item in comparison to the first two items and place it accordingly.
- The team places the remaining cards as a self-organizing group.
- The team continues to size and place items until there are no more items left.
- Fast
- Sizes many items at once
- Easy
- Less accurate
- Provides initial glance at the work
- Doesn't provide much clarification
Tracking the amount of work that got done via the estimated product backlog items that were comleted in a given sprint. Tracking across six sprints; team has been going for about 12-weeks using 2-week sprints.
Acceptable for the velocity of a team to vary over time. People out, or holiday, etc.
- Most Likely: Average Middle Three Sprints
- Best Likely: Average Top Three Sprints
- Worst Likely: Average Bottom Three Sprints
Need to have that much work well-refined
[Defining Done](https://app.pluralsight.com/course-player?clipId=83f573c2-476c-44e1-b54f-aec7c2ff5d4e
The Definition of Done describes all things that must be true about an Increment before it may be released and show in sprint review.
- As automated delivery systems increase in scope, complexity rises
- More frequent discussions are needed to control complexity
- Teams start to meet more regularly for smaller chunks of time
- Teams frequently plan next steps for improvements
- Patterns: Use commonly understood patterns
- Unit Testing: Add unit tests to all new code or revised code
- Automated Build: Automate the building of the code upon commit on a dedicated build server
- Integration Test: Add integration tests as appropriate with each commit
- You arrive at Sprint Planning Meeting
- The Product Owner presents a list of PBIs the Developers have never seen before
- There are no estimates or detail on these items
Refine the Product Backlog Items before agreeing to pull them into the Sprint Backlog on the spot.
- Agile Retrospectives: Making Good Teams Great (PDF)
- Improving Agile Retrospectives: Helping Teams Become More Efficient
- Use a space with no table
- Use a guest facilitator
- Plan the retrospective ahead of time
- Change Techniques
- In sprint retrospective everyone just complains
- Nothing ever really changes
- Now we just skip the meeting (this is a scrumbut)
- Estimation
- The Role of Velocity
- Defining Done
- Sprint Planning Techniques
- Sprint Retrospective Techniques
- Product vs Project
- Stop the Line
- Architecture Implications
- Continuous Delivery
- Distributed Scrum
- Temporary
- Upfront Planning
- Follow the Plan
- Value vs Plan
- Permanent
- Longstanding Team
- Continuous Planning
- Focus
- Production Halted
- Root Cause Analysis
- The Toyota Way
- Anyone on the team may stop the line
- This practice keeps quality high
- Faster Throughput
A stop-the-line event means the Scrum Team will self-organize to solve the problem right away with that root cause. Root cause analysis is the biggest part of stopping the line, not the actual stoppage itself. The reason we stop is because we don't want the team to progress any further that's not working. So, stopping the line gives us the ability to correct things and increase throughput while doing it.
Within some Sprints, the Increment can be delivered with certain features hidden with Feature Toggles. Some Product Backlog Items cut across several Product Architecture Layers.
When teams opt for the expedent over the correct leaving undone work in the Increments that they're creating.
Technical debt accumulates over time. Soon enough, there's enough technical debt in the product that it can take a Sprint or two to pay it all back. You'll never get a Product Owner to agree to a Sprint that just focuses on fixing bugs. That Product Owner wants new functionality and new Product Backlog Items to be delivered. You can negotiate so that you've got extra capacity to go in and pay down technical debt and you'll need a VERY understanding Product Owner to do it. What you're seeing in the blue is what happens when we adhere to a Definition of Done.
Over time, the team must spend more and more time during the sprint either fixing or working around technical debt. This means they get fewer Product Backlog Items delivered as a result. As quality goes down, so does throughput.
- Visualize: Picture in your mind a model of your team's current technical debt.
- Pause & Write: Express that picture in your mind on a piece of paper.
- Plan: It's up to the team to create a plan for paying back this technical debt that you just modeled.
- Act: You've got a document that you can use as a catalyst for conversation. Who will you share this model with and what might a focus for correcting defects look like in your team? What is your team's tolerance for defects?
It turns out that continuous learning and improvement of the team will almost always result in a culture of continuous delivery.
In software development, Scrum Teams deliever Increments of Working Software.
Releasing Increments can happen at any time thorughout the Sprint.
In this model the product is delivered with long release cycles. Increments are delivered at the end of each Sprint. New features and Bug fixes are batched for release. That only happens every once in a while.
In this model, the Scrum Team deleivers Increments at the end of each Sprint and new Software Versions are then released on a regular cadence.
Visual Studio Teams at Microsoft release once per quarter using three-week Sprints to deliever increments along the way. This model has us deliver at the end of each sprint. With a good DevOps implementation this could be delivering all the way to the customer to the end site or to the end prouduct.
In this model, flow and Continuous Delivery is demonstrated. Increments are delivered at ANY TIME and Releases can be decided upon in REAL TIME as Value is delivered. Release decisions are based on delivering smaller Value enhancments more often whenever the Product Owner wants. This establishes flow within the team and focus moves away from big Releases to practices of Continuous Quality Improvement.
Can your team deliever anytime it's requested by the Product Owner? If not, you should be able to do that. To do that, we're going to implement an effective DevOps environment. This is something any Scrum Team should strive for because it gets value into the hands of the customer faster. We are also going to build a Backlog of improvement items for the team. This is something the team can discuss and adpot through Sprint Retrospectives. We improve incrementally over time adopting something like DevOps just a little bit at a time so the team doesn't grind to a halt.
- DevOps
- Plan
- Act
- Yes!
- Is it idea?: Probably Not
- Is it possible?: Things might go just a little bit slower; however, in some instances, the focus that this model affords developers can sometimes increase production because they're not being bothered by things outside the sprint, they are actually able to focus on getting their work done.
- Studies are pending
Team members should consider the ideal working hours that will fit in a team's overlap. When a team has distributed members all across the country, sometimes they'll need to make accomodations for other team members to not always be working too early or too late.
Scrum Teams within reasonable Time Zones and Sizes can work as a single Scrum Team. If it involves more than a few Time Zones, it's time to split into separate Scrum Teams. Someone in each distributed Scrum Team must then represent the team in off-hours time to other teams.
- Working as a team
- Separate Scrum Teams
- Accommodation
A team will tend to self-organize into multiple Scrum Teams based on Time Zones. The more effective the conversations can be, those are the Scrum Teams that are going to work together. There needs to be continuous communication between these Scrum Teams.
This is a simple Scrum of Scrums model that can help us coordinate the work of teams from around the world. In this scenario, each small cirlc represents a different Scrum Team. In model, we can host something called a Scrum of Scrums. It proposes to have representatives from each Scrum Team come together and coordinate their work across an entire product. It's usually the Scrum Master that represents the teams at the Scrum of Scrums and the converation should occur on a regular cadence to ensure communciation is flowing between all the teams.
- Product vs. Project Thinking: The difference between Products and Projects and how focus on a Product inproves quality thereby increasing flow and throughput.
- Stopping the Line: Scrum Teams Swarm on a problem and use root cause analysis techniques to do that.
- Architecture Implications: When we cut thin slices of functionality, we'll deliver a little bit different into our Product Increments.
- Continuous Delivery: Not required by Scrum and does require strong DevOps strategy.
- Distributed Scrum: Developers get to concentrate. Througput may decrease initially as teams get used to the change in communication style. Teams will form along time zones.
The role of leadership as it applies to Agile Product Development with Scrum
- Scrum Masters as Leaders
- Some Management Needed
- Managing a Portfolio
- Economies of Estimation
- The Scrum Executive
- Organizational Change
"A crisis is a terrible thing to waste." -- Paul Romer
Are Scrum Masters leaders? Yes, without a doubt; but, not with a command-and-control mentality...
- Servant Leader: They are there to serve the needs of the Scrum Teams they work with.
- Lead by influence: They are individual contributors rather than a part of the management chain.
- Help Scrum Teams: Job is to help scrum teams be as effective as possible.
- Advise others about Scrum: Advise organizational leaders on the effective use of Scrum to realize the highest possible value for the Customers.
- Authority
- Reporting Structure
- Accountability
- Ensuring Developers Grow Their Craft: Developers, more than anyone else need to be adding to their toolkits all the time. Managers can help ensure this happens by doing things like procuring educational materials, organizing brown bags, and other internal training sessions, or by monitoring learning achievements and helping anyone without a learning plan.
- Ensuring Scrum Masters have room to operate: Managers should stand behind the Scrum Masters as relentless advocates ensuring that others in leadership positions recognize the strategic role of the Scrum Master.
- Managing a Budget: Someone has to manage the money; it's reasonable to think in terms of the sunk cost of having a team in a Sprint but what is total cost of ownership of a Scrum Team vs. the Value being delivered? While monitoring this can sometimes be the role of the Scrum Master, perhaps this sort of booking should be left in the hands of an administrator.
In all Agile circles, the practice of conducting Performance Reviews is highly controversial. One popular idea being that meaningful feedback comes only from one's team. The process should focus on improvement over punishment.
In most organizations, people can use help navigating their own careers, navigating the organization, and finding their way through all that red tape. Managers can help here.
They can also assume responsiblity for seeing that everyone has all the tools they need, that they have ongoing education, that there is hardware available to suit their needs and any software tools that the team needs are on-hand, whether it's for DevOps practices, development tools, or even outsourced services.
"Merit rating rewards people who do well within the system. It does not reward attempts to improve the system." -- W. Edwards Deming (Out of the Crisis)
Managing a set of Products above a singular Product.
- Strategy Depends on Tactics
- Tactics must support strategy
- Operate in both mindsets
Size of a Product Depends on its Revenue; in this case, Product C is delivering the most value.
Can help Scrum Masters know where to focus their energy to remove impediments to teams that are experiencing issues. Those with large bodies of red probably need more help than those that don't.
An example model of how an organization might manage itself and its assets.
- Relative sizing works at all levels of an organization, even for large strategic initiaitves.
- The cost of backlog items can be measured
Focus moves from owner or shareholder value to increasing customer value
- Uses Scrum
- Uses Scrum to manage work across the organization
- Makes data-driven empirical decisions
- Doesn't interrupt Sprints
- Empowers Scrum Masters
- Do Less: limit work in progress at the portfolio level, eliminate waste, create focus, do less in parallel, keep things simple.
- One Team, One Goal: avoid silos by setting up product oriented, co-located, multi-disciplined teams with shared purpose; squash politics.
- Explore and Adapt: rather than follow a plan
- Focus on Value: focus on value over cost, deliver value earlier/incrementally, concentrate on building the right product
- Learn Fast: short feedback loops, tolerate mistakes, value learning and continuous improvement
- Empower Teams: inspire and engage, provide opportunity for intrinsic motivators: autonomy, mastery and purpose
- Collaborate: play nicely, be supportive, give your people’s time, actively participate in projects
- Accept Hard Truths: be open, accept difficult messages, support the team in resolving them; agile doesn’t solve your problems, it highlights them
- Lead by Example: be agile yourself, use agile techniques, exhibit agile principles, adopt a servant leadership style
- Think Big, Start Small: have the big vision, but deliver it in small bite-sized pieces
- Empowering Teams
- Product over Process
- Using Scrum Themselves
- Scrum Masters over Direct Management
Being able to frequently experiment with Scrum is powerful; empiricism is required for success; it's not about Scrum or being Agile...it's about consistently making decisions based on evidence, not your gut
- Education in Agile & Scrum Practices
- True Buy-in for Top-down change to occure
- Teaching and Coaching from Scrum Masters
- Frequent Customer Feedback and Contact
- Support from Management
Organizational leaders need the ability to enact fundamental change across the entire organization. The Agile executive understand they serve the people under them, and not the other way around. This model empowers others to do their best work.
- Scrum Masters as Leaders
- Management can Co-exist alongside Scrum and in Support of it
- Managing a Portfolio (Program Management)
- Economies of Estimation -> Showing we can manage and forecast work at every level of abstraction
- What it means to be an Agile Executive using Scrum
- Organizational Change and what it means to move an organization from where it is today, to what it needs to be