Agile landscape assumes lots of quick churn - requirements grow and shrink, product scope
shifts, technologies are tried on for fit, even delivery platforms seem to be switching
multiple times within project life cycle.
The time where the team has had a chance to learn enough
about the tech, the requirements, the platform, etc. appears to not come until
much later in the project. In the meantime, while the team figures out the tech
and goes along with the experimentation of what the users will find most
useful, every estimate is a wild guess.
Yet, every two (or one, or three) weeks, there’s the big
Question: what do we pull into this Sprint?
On one hand, there are learnings from past Sprints – some things have gotten easier, other things were dropped because they could not be done, some architectural decisions have been made. One the other hand, past Sprint experience shows that unexpected things invariably come up and slow progress to a crawl.
On one hand, there are learnings from past Sprints – some things have gotten easier, other things were dropped because they could not be done, some architectural decisions have been made. One the other hand, past Sprint experience shows that unexpected things invariably come up and slow progress to a crawl.
Then there is reporting. Forward-looking reporting means it
looks bad if the team has not completed everything it has pulled into each Sprint. From this perspective, it is better to estimate
conservatively. Backward-counting from a
deadline where currently-uncertain features are assumed to be required, and
therefore must be packed into prior Sprints with no room to spare for
dealing with the unexpected. There is
very real pressure to load up the Sprint with work that could possibly be all be delivered only under the
best possible scenario.
A less-than-pure approach is flexibility: plan the Sprint
conservatively, with the understanding that the Scrum Master together with
Product Owner will prioritize backlog to pull work into the Sprint if there is
time remaining. This is less than ideal
because having more on the plate leads to higher productivity overall – even if
it’s not possible to complete everything.
Alternatively, a team can choose to plan the Spring aggressively,
pulling more work in, and then reducing the Sprint load if necessary. Unfortunately,
this looks really bad from the outside. Well-meaning teams can be penalized for under-delivering relative to an aggressive Sprint forecast - even when that Sprint forecast was deliberately set up to be unrealistic.
Another option to deal with the planning question is to go
back to the world where teams had a lot of scope-platform-design decisions made
up-front, and could provide somewhat reasonable estimates 3-4 Sprints into the
project. While those estimates weren’t
exactly right, there was predictability earlier in the project cycle. But that would mean giving up the opportunity to learn and to benefit from new discover as the project is being worked.
[ This post is a first part of a series. To be continued. ]
[ This post is a first part of a series. To be continued. ]
