Webinar #5: Sprint Planning Anti-Patterns
•Download as PPTX, PDF•
3 likes•1,202 views
The purpose of Scrum’s sprint planning is to align the development team and the product owner. Both need to agree on the shippable product increment of the next sprint. The idea is that the development team’s forecast reflects the product owner’s sprint goal. Also, the team needs to come up with a plan on how to accomplish its forecast. Easier said than done, it appears. The fifth Hands-on Agile webinar addresses common sprint planning anti-patterns. Learn how to keep a simple scrum ceremony useful by avoiding typical mistakes, from pushy POs, toying with the definition of ready to obstructing the future flow by pushing utilization to 110%.
Recommended
Recommended
More Related Content
More from Stefan Wolpers
More from Stefan Wolpers (20)
Recently uploaded
Recently uploaded (20)
Webinar #5: Sprint Planning Anti-Patterns
- 7. Sprint Planning Anti-Patterns: The Product Owner stefan@age-of-product.com
- 24. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
- 25. Contact Information StefanWolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 17,000 peers) Slack: https://hands-onagile.slack.com/ (Join 3,200 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
Editor's Notes
- Welcome to I am your host Stefan Today we talk about sprint planning… Q&A at the end Please use the Q&A tools that Zoom provides
- my mental model of how agile product creation works: You start with a vision on the left side And you end up delivering code continuously to a resilient system on the right side at will
- I label the left side “product discovery” And the right side “product delivery” Of course, the separation is not as strict; both parts are overlapping somewhere in the “near term planning” era. (In scrum speak it is usual the product backlog)
- Product discovery tends to be much more affordable and low tech on the left side, And much more expensive the further you move to the right side It is literally comparing “a napkin” to a “a full-blown continuous delivery pipeline"
- From a risk mitigation point of view, the further to the left side any discovery activities happen, the more affordable they are
- We started with product discovery anti-patterns Moved then on to product backlog anti-patterns By the way — BOTH replays are available on the YOUTUBE channel And today we focus on sprint planning
- My dirty dozen sprint planning anti-patterns…
- What comes first: team selects stories from the product backlog => PO wrap a sprint goal around them PO defines a sprint goal => team picks stories to match sprint goal? According to the Scrum guide: “Scrum Team also crafts a Sprint Goal“ Scrum great to score matchpoints Matchpoints — for example, providing Paypal to customers — always equal simple sprint goals If finding a sprint goal is regularly a problem => for example, your product is late in the lifecycle => consider why you are using Scrum A metric to track could “meaningful sprint goals”
- Sunk cost fallacy Is the spillover still valuable — best use of the team’s time? Why is there such a level of spillover in the first place: • dependencies? • too much was taken on: • stories not refined enough? • technical debt? • capacity overestimated?
- Last time you took on 25 points, now it is only 17 — how come? First of all Scrum guide: “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team“ Utilization fetish by a pushy POs hence creates tensions, a chasm within the team, Sign of distrust: not a team player? Probably misaligned incentives between PO and the team
- “Definiton of Ready” helpful => sets a quality standard => don’t ignore it However, don’t overdo “PO vs. DEVs” game: • Haggling YES • Stalemate NO => You are playing on the same team DoR not a stage-gate => anti-pattern
- A non-team member – This might be a line manager – defines the scope of the sprint backlog, not the Scrum team =>Popular: random deadlines for features from the management Sign of Taylorism from the industrial age – the foreman is telling you what to do And maybe, you are working in a feature factory
- The development team takes on too many PBI Resulting in a spillover at the end of the sprint Often, the sprint goal will not be reached either (if there is one to begin with) Try to understand the reasons for this — optimism instead of capacity planning? unexpected technical debt, user stories not refined well enough, the need to show that you are busy and thus valuable? Ruins metrics like lead time and cycle time. Tip: take on less, focus on the sprint goal and just pull in new PBIs should you run out of work — after accomplishing the sprint goal.
- Sizing the sprint length after the sprint goal looks smart in the beginning However, it results in confusing cadence of ceremonies, delivery capabilities, and team predictability Distracts stakeholders => for example, sprint review attendees Makes some metrics hard to compare (=> normalization required) Note: doubling the sprint at the end of the year is a pragmatic solution
- The sprint planning is handled by a sub-set of team members, e.g. the PO and the ”team lead” Unless it is the Overall Sprint Planning in LeSS or large scale scrum => true anti-pattern Note: • The development team picks the PBIs from the product backlog • there is no ”team lead” in scrum.
- A classic — no one keeps track of the available capacity overcommitment False signal to stakeholders Spillover Renders lead time/cycle time metrics less useful If repeated => trust issue -> an easy way to impede collaboration with stakeholders Reliability #1 request from stakeholders
- Maximum throughput is achieved at a utilization level of around 80 % No slack time => no flexibility to deal with disruptions: • bugs, • urgent small product increments etc. No slack time => less pairing, less sharing => no longer team work, but individuals at an assembly line
- “Does everyone have enough to do for the next sprint?” no stuffing of features into the sprint backlog 20% slack time 20% maintenance Only 60% for new features => feature factory : 90-plus %; great results in the first 3 months, then technical debt is catching with you
- Sprint planning 2: No planning ahead Too much planning ahead — probably wasteful.
- So, I hoped you considered this webinar of product discovery anti-patterns useful. The next webinar will in two weeks time from now. It will cover the results of a recent survey on which factors are indicating the an organization is agile. And I will also introduce a new open source project — the Agility Assessment Framework — which will support scrum master and agile coaches to figure out the (air-quotes) “state of agile” of an organization.
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large European electricity and gas provider