Please enable JavaScript.
Coggle requires JavaScript to display documents.
Managing Products with Agility / Forecasting and Release Planning - Coggle…
Managing Products with Agility / Forecasting and Release Planning
Release planning and predictable delivery
The lack of predictability of software development is the key to understanding the new model
Manufacturing lives in the predictive world
Software
You can really only know how long something took after it has been completed
Software lives in the empirical world
looking at our history of delivery for similar things, make a pretty good forecast
The best thing we can then do is to expend effort to make that forecast as accurate as possible while accepting that more time spent planning does not necessarily affect the accuracy of that forecast
If you put developers under pressure to deliver they will continuously and increasingly cut quality to meet deadlines.-Unknown
Technical Debt
The first is the teams increasingly have to spend more time struggling with the complexity of your software rather than on new features
The second is an increasing number of bugs found in production. Bugs found in production also directly impact on the number of features that the team can deliver and any bug, no matter how small, costs ten times as much to fix in production than it does in development
¿Handle?
(Definition of Done)
Stop adding new features and make your product meet that checklist and release your product
While you have an increment of working software (Sprint)
Work to create something of value (Increment)
Leave things better than you found them (Engineering Excellence)
Review that thing of value with your stakeholders (Sprint Review, Backlog Adaption)
Reflect on how you worked with your entire team (Sprint Retrospective, Kaizen)
Stop to create and fix
Strategy
Sufficient requirement
Backlog refinement is key to facilitating a flow of actionable Backlog Items to your team
The Development Team chooses what they can deliver
If exist uncertaintly, These Backlog Items can be put on the queue for refinement and refined over the next Sprint
Definition of Done (DoD)
Done for a Development Team should equal what it means to complete an item with no further work required to ship it
Test First
built what the customer expects
engineers build what they expect
Fixed length iterations
If you have variable length iterations you can’t be sure what you can do in a particular timeframe
No separate teams
The most successful organisations at creating software have development teams that own the entire application lifecycle
This means no separate test teams, configuration management teams and definitely no separate maintenance teams
Manage dependencies
A Development Team should have all of the skills required to deliver what you want at the quality level that you want
However, if you have a dependency on a separate team, maybe you have an application upon which all of your other applications depend, then you may need another way
Scrum Myths: There is No Planning in Scrum
In Scrum, we emphasize the activity of planning over the plan itself.
We know the plan is going to change
Planning in Scrum is part of every Event
In Scrum, the way planning is done reduces waste
A plan is out of date a minute after you discuss it
Some ways that we reduce waste related to planning include:
We minimize time spent analyzing things that may never happen
We minimize time spent analyzing to an impossible level of accuracy
There is a point where our gains in accuracy no longer outweigh the time spent to get there
We accept that the complexity and unpredictable nature of software development make it impossible to have a perfect plan
We incorporate meaningful feedback every time we plan
we can be transparent about the current progress and likely completion dates
This helps us build trust
This enables us use an empirical process to enable business agility
Faking It: Estimates and Metrics in Scrum
"The most important metrics are: did we execute the way in which we said we would, and did we deliver the value to the business that we had promised?" - Jamie S. Miller
Thus agile teams, empirically by the incremental release of value, over how much estimated work they appear to have "delivered"
value the empiricism which would allow informed decisions to be made.
Having taken these measurements the teams which own them can then make reasoned forecasts
Completing the original forecast of work arrived at during Sprint Planning is, in truth, somewhat irrelevant.
The critical thing is to have a plan which allows the Goal to be met
In essence, measuring how much work is left in the Sprint Backlog ought to be nothing more than an exercise in forecasting goal actualization
Burndown Chart
These measures are only useful to the teams which make them, within the context of their Sprint and their own development concerns
A Sprint Burndown is a forecast of the work which remains to be done by a team
Why Estimate?
The delivery of working features, early and often, is the only measure of progress which can be truly satisfactory at any scale
the only purpose of estimation is to allow a Development Team to figure out how much work it thinks it can take on
PO is the one customer representative who must lie within the Scrum Team circle of trust