Estimating Sprints aka the problem with Scrum

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.

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. ]