Guest post by Ankur Saxena
Many agile teams today often struggle with the concept of Points and Hours. For some agilists, estimating user stories using points is the way to go, as hours are precise units of time, and are incapable of estimating an evolving requirement. In their opinion, they do not provide the flexibility necessary for the process of progressive elaboration. Then there are those who are new to the world of agile, and are torn between the traditional mindset, and the agile philosophy. They sometimes naturally lean towards estimating requirements in hours, as ultimately it is the time, and not the story points that matter to the stakeholders. Whether it is time to market, or time to develop, build, and test a product, calculate budget etc, it all boils down to the number of hours. These two camps are like two of a trade that never agree. There is also a third camp that accepts the idea of them coexisting, but strives to establish a relationship between the two. They are of the opinion that as agile teams mature, enough data can be gathered to quantify their relationship.
The important question is, why is there so much confusion around this subject? Part of the reason is that they both are used as units of estimation, and are generally viewed as substitutes for one another, when in reality they both serve different purposes, and capture different project management dynamics in the agile environment. Ideally we need both to properly monitor project progress and meet our service level agreements.
Let’s take a brief detour and venture into the world of traditional project management, where the work effort is measured in hours, and emphasis is on coming up with the “precise estimates”, which, in my opinion is an oxymoron. Traditional project management relies heavily on upfront project planning. It is built on the premise that a project is predictable if the business spends enough time upfront in understanding the nature of the work, identifying and documenting all the project needs in great detail, negotiating the project scope, and finalizing a contract agreement. But we all know that with most software projects it is seldom true, and they are anything but, predictable. Estimating effort in hours with any level of accuracy requires stating of precise and detailed requirements, which is difficult to achieve during the inception phase of any project. In order to account for this cone of uncertainty, we need an estimating mechanism that is based on the principle of relative sizing. Points give us a way to do just that, as do t-shirt sizes, or gummy bears. They allow us to manage the uncertainty associated with the high level requirements by relatively estimating their complexity, rather than trying to estimate the effort in absolute terms. Points also help in building consensus during planning and estimation. Most teams find it easier to determine, and agree upon the relative size of a user story, instead of coming up with the exact number of hours to accomplish it. As an example, team members may easily agree that creating a reset password feature is a more complex task compared to adding a help link on a webpage. But based upon an individual’s level of expertise, each team member may take a varying amount of time to develop that feature. This is why it becomes much more difficult to build any kind of consensus using hours.
Does this mean that unless we start conducting our Sprint planning meetings, we cannot provide any kind of timeline to the customer? Absolutely not. In fact it's quite the opposite. During the inception phase of the project, when the product is still a concept, and the requirements are being continually refined, a high level product roadmap, and a release plan are created to communicate a rough timeline to the customer. In my opinion, it is always better to be roughly right than precisely wrong. A release burn up (or down) chart can be used as an information radiator to communicate progress at a glance to the customer. As finer details are worked out, and the cone of uncertainty continues to shrink, the release plan is frequently updated after every iteration to account for any evolving requirements, or change in team’s velocity. A release plan is simply created by assigning story points to each user story, and then calculating how many time boxed iterations we would require to deliver the final product based on the team’s velocity. So for example, if a team has to deliver 600 story points, and for a 2 week iteration their velocity is 60, then they would need 10 iterations, or 5 months to deliver the product. Of course it will change as the product continues to evolve.
All this talk about velocity provides a nice segue into my favorite and one of the most important aspect of story points. Story points help us determine a team’s velocity, a key metric for measuring a team’s productivity, and capturing critical team dynamics. Team velocity allows us to paint an accurate picture (rosy or grim) of a team’s performance level, and is a true measure of a team’s capacity, something that hours are incapable of capturing. Unless a resource is removed or added, the total number of available hours within a team don’t usually change, but a team’s velocity can fluctuate from one iteration to next. Even when resources are added, especially late into the project, the team often reports lower velocity and reduced productivity. Had it not been for the velocity, this team dynamic would not have been captured. In fact, many people who manage software projects using traditional practices are still shocked, when adding more resources to a team does not result in any productivity gains. Measuring velocity drives us towards continuous improvement, and encourages us to constantly inspect and adapt by making us ask the right questions on a regular basis, which is the key to building high performing teams.
Okay, we have been talking about the enigmatic story points for quite sometime, but what about hours. Where do they fit in the grand scheme of things? Stay tuned to the blog to read about the importance of hours, and the final verdict.