Evolution of Software Estimates

Status takes a different approach when creating software estimates. It focuses on providing blocks of time or hours based on the Fibonacci scale. This strategy provides an immediate understanding of an estimate and blocks of time instead of overly precise estimates with detailed durations, think 8.9872 hours. This process is a change from using the standard approach of story points in Scrum. Let's see what formed our strategy.

Here is our long journey with story points over the 15+ years:

1. It took a while to understand story points. We went to user groups, brought in consultants, and read a lot of material about them. We finally grasped them as a relative estimation akin to T-shirt sizing or thinking of them as jobs a painter or landscaper might say, like a residential home being a small-sized job and an elemental school being an x-large job. But it's all relative based on what is expected of your teams and what they are accustomed to. Those who always paint elemental schools all the time might say that they are small jobs, and a college is an x-large job.
2. We also struggled to gain consensus on the story point values, so we introduced story point poker to ensure everyone understood the point values. If team members had different story point sizes, we would hear in detail how each team member came up with their estimate. This shared team knowledge would be valuable for the next round of estimation. These meetings took hours of discussion and were time-consuming.
3. We had a good process with story point poker as long as the team was consistent. It was very slow for new teams to reach a shared awareness of story point values. We started experimenting with various approaches across teams as we sought ways to get team members to understand story point values quickly.
4. It was faster to match story points to hours at the start of new projects and then stop using hours after everyone had a rough understanding of story point values.
5. Then we discussed hours over story points. Using hours-to-points, teams quickly reached a common understanding for anyone joining or forming a team. It provided anyone outside a team with estimates they could understand; it was a win-win. The hours-to-point conversion was widely adopted.

This journey became one of learning the best and most direct approaches to sharing estimates with others. We no longer had to figure out a velocity number to guess how we were progressing; we could state our capacity and what we were doing at that time. Adjusting our process was a natural evolution toward continual improvement and better outcomes.

Let's review two significant differences in the Scrum methodology process compared to what is in Status. We want to address these differences because some of you might already recognize some anti-patterns to conventional Scrum guidance. First, hours-to-points is nothing new and is often mentioned as an anti-pattern. Second, story points should be about complexity vs. time. Remember that Agile isn't about being stuck in rigid mindsets; it's about embracing flexibility and openness to change.

Hours-to-point conversations are ubiquitous because they work on a universal shared understanding of time. Why not make the estimation easy to understand or KISS it? We moved to story points because we wanted to move away from detailed estimates in the waterfall project methodology to something less precise. That's why Status doesn't allow the input of specific estimations, only "buckets of time."

The argument between complexity and time has been ongoing. Based on our experience and some agile experts, the debate should be settled now that time determines a point value. Complexity is subjective based on who is doing the work. A small user story point value could be difficult for a junior team member and require a higher point value, or a large pointed user story could be straightforward for an experienced team member and need a smaller point value. The estimate should be based on who is doing the work, not on the perceived complexity.

Our 'Status' approach to software estimates is not just a strategy change but a commitment to understanding, simplicity, and consistency. By prioritizing these principles, we aim to streamline the software estimation process, enhance collaboration, and deliver more reliable outcomes in software development projects. We believe in this approach's power and potential to transform the way we estimate.