One topic I find to be a source of microscopic dissection by Scrum teams and business stakeholders alike is Agile estimation. How good can we get at predicting the team’s output or improve the lack of confidence in a team’s estimate (i.e. sand bagging) are examples of some of the conversations swirling in and outside team. Add to that the psychological aspect of teams that exhibit the “we want to please the business” mindset or “gaming” the system to keep the status quo, its debatable whether estimation using the Fibonacci sequence is effective at gauging what it takes to deliver a story. As many software organizations look to continuous delivery to keep up with increasing customer demands spurred by unprecedented internet and social connectivity, the paradigm may shift from how many points are we burning to how long will it take to complete certain batch sizes of work.
Is it just complexity or effort or both?!?
I imagine Scrum masters can relate to the “so are we estimating complexity or how long it’s going to take or both?” question from their Scrum teams during planning poker. If not then try explaining the correlation between the mathematic sequence and effort/complexity/size to a room full of developers and QA folks after a heavy lunch. It’s also challenging for stakeholder’s to wrap their minds around the concept of “points” when all they really care about is how long will it take to get their customer’s requests out the door.
Through cycle time analysis, user stories with complexity estimates can be reconciled to the amount of time they took to deliver. Based on data collected, I’ve seen cases where work that was given higher complexity (e.g. 8pts) actually took as much time to deliver as less complex stories (e.g. 2 or 3 pts). Conversely, I’ve also seen that as teams mature, work batch sizes get grouped into similar sizes (small, medium and large). Now naturally “you don’t know what you don’t know” when estimating a story but after studying cycle time data over several successive sprints it is possible to see common patterns in time to deliver based on size of work.
Regardless of which estimation method a team uses, in order for it to be useful the team must be empowered, have clearly articulated outcomes and quality measures along with buy in from all participants required to deliver work (e.g. POs, UI/IX, DevOps). Given these conditions, once a team can establish batch sizes of work and corresponding cycle time (e.g. small <= 2 days, medium <= 4 days, large <= 6 days), experience has shown that estimating in ideal days is not only easier for teams to wrap their minds around but a more consistent form of measurement. Ideal days also take into consideration complexity and effort to deliver and can be challenged/discussed by Scrum team members during planning in the same way as traditional Fibonacci estimates. Additionally, monitoring ideal day estimates during an iteration (at stand up for example) can also serve as a flag when a story is stuck in the value stream close to or past it’s initial estimate.
Ideal days as common currency for planning
I can almost hear an instinctive response by seasoned POs, “How do I predict a teams ability to deliver over successive sprints without points?” Let’s not confuse leveraging ideals days instead of the Fibonacci sequence for estimating as doing away with velocity for time boxed iterations. I’m merely suggesting that another standard of measurement be leveraged. One that can provide a common currency to which everyone internal and external to the team can relate. If work can be relatively batched, throughput (number of work items produced over a given time) is another “real” indicator of how much work the system can handle during an iteration. In practice, POs faced with a backlog of sized work can also leverage throughput in concert with ideal day based velocity as an aid in “guesstimating” how many features can be produced over several sprints in the future.
Why should we do estimating anyway?
I’ve read several blogs posts and articles debating whether estimating is a wasteful practice since – as some would put it, gets stakeholders fixated on a value that is subject to the rigors of software development yet holds the teams “foot to the fire” if not delivered as planned. However, I do see the value in collecting data and understanding what the system can deliver and when so as to give some level of predictability to satisfy customers requests. Not to diminish traditional Scrum here but in my experience leveraging ideal day estimates can help teams better understand when and how much value they can deliver over time. For me it boils down to a question of what’s more important; tracking points or actual units of shippable software?