Scrum in Practice
About
Initiation
Define the Product Vision.
The PO will discuss with the stakeholders to define a product vision, that is clear and short.
The Scrum Master will help maintain this meeting as productive as possible.
Define the Product Strategy, which is how is the Product Vision be achieved.
Part of this is defining one or more Product Goals.
They are manifestations of the Product Strategy.
They are keys for giving the Scrum Team a concrete strategy on what it needs to build to deliver a valuable product.
The PO and entire Scrum Team should be evolved with Stakeholders to come up with the Product Goals.
Defining the Product Backlog.
Detailing everything necessary for the product, but with the right level of details. just-in-time
Meaning that we will detail just enough items for the upcoming Sprint.
In the beginning all the items will be EPICS, an then will be refined to be more concise and specific.
Refinement can be done with User Stories this means:
Writing a Card which is a description of the functionality, valuable to a user or customer. Must be written from the perspective of a customer or user.
As
[actor], I want[action]so that `[end].
Conversing, which represents the collaboration between the PO, the business people and Developers.
Confirming, which is a list of criteria that the Scrum Team will define to serve as verification if the product delivered suits the needs.
List of criteria that must be satisfied. (Just like Test Cases)
After creating the items, we now need to order them. Could be done ordering by:
Return on Investiment (ROI)
Value
How much value it will deliver.
Size
How much work has to be done the deliver this item.
Is it fast or slow.
The ROI takes both into consideration by .
Risk
A riskier User Story is the one that depends on things that the Scrum Team is not familiar with.
And they should have higher priority, since if they don't work, less waste will have been produced.
Dependencies
The dependencies between User Stories must be also considered.
If a higher ROI item depends on a lower ROI one, the lower one will still have to be done before.
Define the business value using Kano.
How can infer the value of User Stories?
With the Kano Model:
Classify the Backlog items in:
Mandatory. (Higher priority) (All of them must be at the Backlog)
Linear. (Medium priority)
Exciter. (Less priority) (Should have a few)
But, to be able to order we first need to be able to estimate the values:
This will be done with Story Points and Planning Poker.
Story Point will be in a scale of:
1, 2, 3, 5, 8, 13, 20, 40, 100.It is a team metric.
The estimation itself will be done with Planning Poker.
A collaborative consensus based agile estimating technique.
For the first time, you will select the smallest and easiest User Story, and give it a Story Point of 2. The other ones will then be relative to this one.
Construct the Definition of Done:
Sets of Criteria like:
Quality assurance
Architecture
Non-functional requirements
Process management
Configuration management
You can also define Done in different levels:
Task
Product Backlog Item
Sprint (Increment)
Release
Project
Form the Scrum Team, considering: - Hard skills: (There must be redundancy here - multiple devs with same circle of knowledge - otherwise they cannot help each other) - Technical Factors: - Knowledge about methodologies, - Processes, - Technologies, - Tools - Soft skills: (How well they work as a team) - Social Factors. - How good is their communication. - Personality. - Interpersonal Abilities. - Individual Costs. - You can bring all the candidates members together and let them organize into Scrum Teams. - Or make existing teams propose the new Scrum Team.
Now you develop a Release Plan to bring alignment with the team and choose the Backlog items to be in the release.
It can be built with a Feature-based approach:
Fixed Scope, but let Time flexible.
Select a set of Project Backlog items and plan how to deliver them.
Or can be built with a Date-driven approach:
Fixed deadline, flexible scope.
Now you can estimate how many sprints it will take to burn all the Story Points to get this release done.
You will create the Best and Worst case scenarios, discussed in the Cone of Uncertainty.
You can use historical data, on how many points usually the team can burn in 1 Sprint.
Otherwise you will have to predict the velocity:
By analyzing a Backlog Item, an how many hours it would take to complete it.
You must consider that the team wont have 100% effectiveness, it will be from 55% to 80%.
So if they in total work 100 NOMINAL hours per week, they will in practice work only 55 to 80 REAL hours.
If this Backlog item has 10 points, and the team can complete it in the Sprint in 50 hours, then it will take them 5 hours/print.
Thus they would be able to burn in a Sprint to points.
The Release Plan must be updated at the end of every Sprint, in the Sprint Review.
You never decide the Sprint Length after you pick the User stories for the Sprint.
Planning
Refining the Product Backlog items can happen:
During the Sprint Planing.
Or by having a separate Refining Meeting.
In the Sprint Planning:
Must Address:
Why is this Sprint valuable?
Discuss the opportunities to increase the products value and utility.
How this can address this.
Scrum Team defines a Sprint Goal:
It communicates why the Sprint is valuable to all stakeholders, brings transparency.
Sprint Goals should not be defined after selecting the Backlog items.
What can be Done this Sprint?
Break down EPICS into smaller User Stories.
Define how much can be completed during the Sprint:
See upcoming capacity:
How many hours available the Devs have for this Sprint.
If anyone will be off the office.
Could consider past performance or consider the Team Velocity.
How will chosen work get Done? (The Plan)
Create the Sprint Backlog and the Plan:
Decomposing the Product Backlog Items
Team can design a sketch of the solution, to have an overview of what needs to be done.
After decomposing and learning more, you gather and check if more can be included, if things need to be removed, always thinking in the Sprint Goal.
Then you have a Sprint Backlog.
After the Sprint Planning is finished:
ONLY the developers can change the Sprint Backlog.
And the Sprint Backlog is the ONLY source of work for them.
Execution
The Sprint is when the done usable potentially releasable product increment is created.
Developers should not be interrupted with demands that are not focused on the Sprint Goal.
During the Sprint in Software Development this is executed:
Requirements
Architecture
Design
Implementation
Testing
Unit Testing
Integration Testing
System Testing
Ideally, the Scrum team does all the work necessary to deliver the product.
But in some cases, part of the work will be done by external team.
The Daily Scrums:
The developers don't plan only in the Sprint Planning, they also plan daily with the Daily Scrums.
To talk about their progress and synchronize work.
Each one must answer:
What did I do since last meeting? (Can be ignored, to only discuss the future)
What will I do until next meeting?
Do I have any Impediments?
Tips on Daily Scrum:
Don't share shallow information.
Don't discuss technicalities.
Sprint Burndown are usually done in the Daily Scrums.
6 indicators of bad Daily Scrums:
Team members are reporting status to Scrum Master or PO.
Some members arrive late.
Taking more than 15 minutes.
People share shallow information.
Some members don't pay attention to what others say.
Scrum Master or PO manage turns.
When the Sprint is almost over, an everything is almost Done, the Team could refine some Product Backlog Items for the next Sprint.
IF there are disturbances in the Sprint, you cannot blindly follow the Scrum rules. - You might have to cease a bit if necessary depending on the case.
What to do with Product Backlog items that are not Done by the end of the Sprint?
The incomplete items are moved back to the Product Backlog.
Inspection and Adaptation
The Sprint Review (The goal is to inspect the Increment and adapt the Product Backlog if needed)
The developers will check which Backlog items are Done.
And prepare them to be demonstrated in the Review.
Inspection:
After getting the feedback from the users and stakeholders.
The Scrum Team will discuss the Product backlog.
Given the release plan, the PO might discuss the likely target and delivery dates, by using the Release Burndown chart.
Product Backlog Grooming:
Usually the grooming is not done in the Review, since it takes a lot of time, and the review should be used to rise these feedbacks.
These can be part of the Backlog Refinement Sessions on Sprint Planning.
Or in separated Workshops after the Sprint Planning.
The PO doesn't need to wait until the Sprint review to inspect and give feedback to the developers on what has been done.
Don't rely only in the Sprint Review to get feedback from Users and Customers.
The Sprint Retrospective
Avoid using the same methods in the Sprint Retrospective.
Questions to be anwsered:
What went well during the Sprint?
What didn't go well?
How can we improve?
5 steps of the meeting:
Setting the stage.
Welcome people and reiterate how important the meeting is.
Review the Improvement List.
Presente meeting structure.
Gather data.
Gather all that happened, for good or bad during the Sprint.
Generate insights.
Improvement Points.
Lessons Learned.
Decide what to do.
Which actions will be put for next Sprint.
The most impactful improvements are addressed as soon as possible.
The may even be added to the Sprint Backlog for the next Sprint.
Treat improvement items as backlog items:
Retrospective Planning Poker.
Close the meeting.
Last updated