Let’s begin this article with a recap of what we’ve covered. We started out with the argument against time-based estimates. We then sought to answer the question “How big something is?” using story points and relative sizing. Next, we attempted to meaningfully respond to “How fast can we go?” and explored the concept of velocity in that context. Now, we move on to “When will all of this get done?”
The question is not meaningful
While we may be eager to know the answer, the question “When will all of this get done?” is not meaningful and needs to be rephrased for 2 reasons:
- While Raw Velocity is a logical starting point to estimate how fast you will go, the averages derived from it remain guesswork. It offers us a reasonable starting point that must be periodically revisited once actual work commences. The numbers are bound to change in real work situations and that presents a challenge. To illustrate this: If your scope is 200 points and the Raw Velocity is 10 points per iteration, then it’s safe to say it will take 20 iterations to complete the entire scope. But once you start working, you may realize that this 10 itself is going to change–it may come down to 8 or 5, or even go up to 12. This fluctuating number affects the response to “When will all of this get done?”
- Moreover, the “all” in question, i.e., the scope, is also variable and therein lies the second challenge. You may have estimated 200 points as scope while initiating the project. But dynamic situations in the market or the organisation can impact this number. The scope is very likely to change over the course of the project and it’s prudent to proceed with that awareness.
So, what we know is that neither the scope nor the velocity will remain constant. Hence, the question “When will all of this get done?” has no real value.
What, then, should we be really asking?
The Triple Constraints Triangle
Before we frame the right question, let’s take a step back to understand the oft-cited paradigm of project management – the Triple Constraints Triangle – and how XP connects with it. Scope, Time and Cost are the 3 points of this triangle, with Quality as the central, overarching theme. What happens if we arrange these 3 constraints into different permutations?
- Flexible time, fixed scope and cost – This is not advisable because we could spend years building out “all” the (ever increasing) scope we can think of, but not be able to reap the benefits of the software we are building. This has been the fate of many-a-traditional software projects.
- Flexible cost, fixed scope and time – Keeping cost flexible essentially means agreeing to varying the team size in response to variations in scope or velocity. However, growing and shrinking the team is neither feasible nor useful.One of the most important ingredients of a successful software team is the context and the knowledge that they build over a period of time about the problem at hand and the solution. A team that’s constantly changing its composition will not be able to take advantage of such a benefit.
- Everything fixed – The biggest casualty in this scenario would be quality because if everything is fixed, quality is the only thing that can change and it will change.
The XP view of Triple Constraints Triangle
The third permutation is typical to traditional software development. XP, however, takes a different view. We advocate keeping quality fixed at the highest possible level as well as freezing time and cost, and keeping scope as the only variable. Freezing the team size (i.e., the cost) is age-old wisdom that adding people to a late software project makes it later. And, time must be frozen too and you should commit to yourself and to your stakeholders that you will go live by a certain date.
However, be mindful that the concept of “freezing time” in XP refers to freezing time in multiple small chunks or iterations. At the beginning of each iteration, ask yourself how much will you get done in that period. And at the end of each iteration, be sure to deliver something into production.
The meaningful questions to ask
Having understood and accepted this XP-variant of the Triple Constraints Triangle, we frame the right and relevant questions that you should really be concerned about:
- “How much are you able to do in each iteration?”
- “What should you do in the next iteration?”
Now the focus shifts to prioritization. Instead of debating over the timeframe for the entire project completion and then scrambling about to achieve that, you are now asking what should be completed next. You are systematically breaking down “all” the scope into small releases and iterations. By asking yourself the above 2 questions regularly and frequently, say every 2 weeks, you nail down a priority list. This also helps in appropriately spreading work out over iterations.
The correct questions reduce pressure
The exercise of Raw Velocity–as we saw in previous articles–provides a good starting point. Since it’s an average derived from multiple developers across multiple stories, it instills some confidence even if it’s guesswork. As you progress with these numbers, the guesswork gets replaced by real numbers derived from real data. The first few iterations give a more realistic estimate of how many story points can be completed per iteration, and this Actual Velocity–based on real experience–guides future iterations.
Having understood how much can get done in each iteration, you can now prioritize what to take up in the next iteration. For example, if the last 3 iterations showed you that it’s possible to complete 10 points per iteration (that’s the response to our first question), you can then decide which 10 points to take up next (the response to the second question). Such prioritization helps you move the most important features ahead in production. And this momentum of continuous delivery ensures the project doesn’t lag behind terribly or goes completely off-track.
Here’s a practical scenario borrowed from the real world to illustrate the above:
We’d said we’d go live with a set of features in 3 months. At the end of 3 months, we’ve built 80% of the features. It’s imperative to now go live with that 80%. The good part is because we have effectively prioritized what needs to be taken up in every iteration, we have covered the most important aspects of those features in that 80% and in the estimated 3 months. The remaining 20% will get covered in the next few weeks or so. The client doesn’t have to choose between “We’ll go live with everything or nothing”. They feel assuaged that the most important 80% is out there already and the remaining pieces will be put out shortly. Likewise, the team doesn’t feel pressured about performance or productivity, keeping the environment positive and collaborative.
Prioritization enhances outcome
We reiterate that such prioritization and focus on “What to do in the next iteration?” also ensures that you take the most valuable pieces into production first. What needs to get delivered on priority gets picked up on priority. When you’re thinking about what should go into production next, here are 2 useful approaches:
- Learn from software that’s been put into production. For example, you have previously built a feature to increase conversion rate of your customers. Now, you may want to evaluate the progress of that metric and assess how it can be made more effective. So you can pick that up as the next piece to deliver based on what’s already been done.
- Get early feedback from real users and use that as a guide. Build prototypes to carry out user testing with real users–even before you write a single line of code. Analyze its results to determine what your users really want and schedule that as your next to-do item.
It’s important to note that we are making space for new scope. We’ve accepted that scope will change and we welcome that. Based on yesterday’s weather – average of actual velocity from the last few iterations, we can go back and identify what to pick up next. We may even end up identifying new features to build in the next iteration based on user/market response. Our process of prioritization and our Velocity numbers give us room to be flexible in order to deliver what is critical and remain responsive to what users want or what the market needs. In a nutshell, we’ve ensured the outcome is truly effective and efficient.
Let’s pause at this point for a quick review.
“When will all of this get done?” is really not the question you should fuss about. Instead, you should try to answer the question “How much are we actually able to do every iteration?” and then concentrate on prioritising the most valuable functionality at the beginning of each iteration. We recommend keeping scope flexible, while freezing time, cost, and most importantly, quality. Freezing time in XP refers to the concept of of iterations–with the emphasis being on continuous release into production at the boundary of each iteration or even more frequently if possible. This practice of Continuous Delivery works hand in hand with Continuous Discovery–as we investigate and assess the next valuable thing to take up next. And to do that right, we either learn from software that’s already in production or use feedback from user testing.
Going forward, we will see how this XP perspective of software development and project management successfully overcomes many of the typical hurdles that are common in the traditional development space that uses time-based estimates.