Sprint is a cycle lasts 4 weeks
- Don't like the name, not sustainable
- 2 weeks more common
- No gap or delay between sprints
Sprint goal
- Valuable, clear, realistic, won't change
- Not changing the goal is important to not affect motivation.
- Help coordination, create visibility, surface problems, protect team
- Protect the goal from changing during Produce stage
- Only way to change goal is to cancel the sprint
- Examine carefully
- The Product, what we are delivering
- The Process, how are we communicating and estimating, etc.
- Find future improvements
- Feed changes into the plan
At the start there is a kickoff. Multiple sprints should have a lot of improvements At some point there is a release.
Do activity to the end of the timebox Got to stop at the end, cannot finish late. Sprints have timebox Planning and retros have timebox Everything has a timebox Prevent processes from taking too long Help us to learn and improve Force improvement
- Stand in circle
- Update everyone
- force the ending of stand up
- Have to stop
- The coach is important to meet the goal within timebox
- Sliding on the timeboxing, not enforcing
- Gradually yielding to more time
- Chaos is our enemy
- Team must have buy in
Scrum doesn't work for everyone Do a sample sprint and work from there
3 key players PO, Dev Team, Scrummaster. Supporters: help or don't get in the way.
Main responsibility: Maximise value and satisfaction of product It's not about the amount of features, it's about the impact of the features. Needs to have deep understanding of customer and clear vision for the product. Receives input from many inputs but PO must make decisions. It's a specialised role Product Owner can be development team PO can be in 2 teams But PO cannot be the same person as SM
- Everything that the product needs, prioritised list of everything needed
- PO decides the tradeoffs between different dimensions: scope, schedule, cost, quality
- Different dimenions will pull you away in different directions
- Must land in the intersection: The Right Product
PO and Dev collaborate a lot
Self-organising, Cross-functional Programmers, testers, etc... are all referred to as "developers". Because everyone contributes to the final product, and we don't want them to think in silo.
- Individuals who have one of each of the required skill
- Individuals who have all of the skills needed
- Recommended size is 6 +/- 3.
- Smaller teams tend to work better Colocation helps to commit and communicate
- the point is to not continue doing what doens't work.
- make changes to meet the sprint goal.
Scrum is not prescriptive Don't continue doing what doens't work Try something different Experiment and then try for 1 sprint
If Scrum doesn't prescribe the solution, then use common sense and try for a sprint – or a few sprints.
Leads the chagne Teach and coach Scrum theory, practices and values Referee Scrum rules Encourage trasparency and honesty Remove impediment Protect from disruption Leads through serving not directing
- Don't take responsibility away from the development team
- Understand why and then facilitate the team towards a better outcome instead of just spoonfeeding
- Coach the team to take responsibility, help them be more motivated Most teams are not motivated, SM's main challenge
Adding more pressure and expectations gives a temporary bump to productivity
- Burnout will set in and productivity drops
- Pressure doesn't go away even after productivity drops
- Impediments
- anything that slows us down, creates waste and hurts motivation When impediment is removed, productivity increases hence better output People must reduce the impediments, SCRUM does not magically make it go away.
- Most scrum teams have 70-100 impediments
- The first step to solve impediment is the most difficult
Wrap things up, capture opinions
Have a scale for opinions
Technical disagreements, can't get consensus Do spike
For deconflicting
Product backlog items
Most of the PBI is made up of featuers Attach items to PBIs Some teams use User Stores as PBIs
- as long as it has direct value to customer
Things that don't directly affect user
Things that don't directly affect user
spike cards
If PBIs are not planned from user perspective as working features, then we don't know how much of a working product we are shipping. If no working product is shipped, we don't knnow anything about it.
Before first sprint Spilt into smaller stories and slicee
- Not split into technical components
- But smaller in scope and complexity Each feature has different value, so prioritse according to value
80% of value is delivered in the first half of all sprints before release
- Good POs will put items that can be dropped or postponed at the lowest priority
Development team estimates how long the sprint will take
- Realistic goal
- Sense of commitment
- Backpressure to manage team burnout
- includes feature, and testing and bug fixing
- testing is done within the sprint so that defects do not snowball
- agile testing
- PRI - "potentially releasable increment" The current sprint goal does not change, but can be swapped around
Can put on the top of PBI, and remove the low value items Value is increased overall, but schedule cost and quality maintained the same. Scrum allows for accomodating changes
Software development is a game of skill, not a game of scale
Some PBI will not be completed Can go back to the top of PBI stack or anywhere in the stack according to prioritisaion These can be mitigated with Scope bufferring, schedule buffering, cost buffering
Use extra time to start next item on PBI or technical items But sprint goal is not changed
Feature goes back into PBI stack