Practising XP

To corroborate our advocacy of story points over time-based estimates, our last article recommended the use of Relative Sizing to answer the question “How big is this task?” We ended that piece by highlighting how the sizing process provides a good grip on the project’s scope. We now move ahead in the estimation and planning journey to the next question “How fast can it be done?”

“How fast?” has no concrete answer

The stark truth is that the question “How fast?” cannot really have a correct and definitive answer. The only honest answer is “I don’t know.” Many factors contribute to this ambiguity: 

1. Team composition – How fast can the team get something done directly depends on who is on the team, what’s their experience with this specific technology, and their overall exposure and experience within the given domain. 
2. Team dynamics – However, it’s not just about putting the right team together and ticking off the technical requirements. It’s important for the team to collaborate efficiently and harmoniously. They must be able to work well together in order to get things done. 
3. Environmental factors – The ecosystem in which the team will work also affects their speed. For example, will they use fast machines, fast internet, and fast servers that serve data quickly? Or will it be virtual networking and logging on to remote terminals that can compromise the pace of work? Even if the team has ideal experience and exposure levels, such environmental factors will have an effect. 
4. Business stakeholders’ response time – This impacts task completion in a big way. Are clients available to answer your questions as soon as required? Can anything in their work environment lead to deprioritization of your questions? Maybe they don’t have the answers ready and need to conduct research or ask around…delaying their response time and consequently the team’s progress. 

Answering the “How fast?” question helps planning

Given the above unknowns, the only honest answer remains “I don’t know.” Any claim to a precise response should raise suspicion because nobody can really know.

If not knowing is the only thing we really know, do we still need to even address this question? And the answer is yes, we do, because its response guides the important activity of planning. Planning is a must because it gives us a chance to uncover assumptions, become aware of risks, and get a clearer picture of the reality of the project. Of course, with the caveat that the response is going to be based on guesswork. 

Keep the guesswork logical

Within this framework, we must be as logical as possible while estimating how fast we will go. That can be achieved by making more people guess how fast they can go about various items in your backlog. Ask them questions about different stories, types of technologies, the UI, database, services, and the interplay between these. Gather all these myriad responses and average it out. So you’ve got as many inputs and insights as possible into a wide range of relevant concerns. Averaging all that will help you make headway–but it will still be guesswork. 

Raw Velocity provides a logical starting point

We recommend doing this guesswork logically by using the Raw Velocity exercise. Let’s quickly understand what it is and why do we recommend it: 

1. Enlist 4 or 5 developers with diverse experiences and exposure to your technology and domain. The more diverse they are, the better off the results of the guessed work will be. 
2. Assign Developer A a batch of 10 random stories from your backlog of say, 100 stories. Offer a mix of story points, features, etc.. Make sure you hide the size or points. Get an understanding from the developer how many s/he can do in 1 iteration (the timespan of an iteration is fixed, e.g., 1 week). Essentially you are asking Developer A how many stories s/he can get done in 1 week. 
3. The developer assesses the size of the stories and gives the response. For e.g., s/he could say stories P, Q, and R from this batch and they turn out to be 2 Smalls and 1 Medium. So Dev A can do 4 points in 1 iteration. 
4. Give Dev A more batches of 10, and at the end, average out their responses. 
5. Conduct similar exercises with the remaining developers.
6. Finally average across rounds and across people–and that average is your Raw Velocity. 
7. You then factor in other variables such as paid time off, unplanned leave, etc. and calculate the team’s planning velocity. 
8. This is then used to create an initial plan that is taken to the stakeholders and expectations are set. You can start development with the points you get from the Raw Velocity exercise. But 2-3 weeks later, revisit these expectations because the real picture and real feedback once you start work will input additional–and more valuable–lessons. This initial plan will keep evolving over time based on real, observed velocity.  

Advantages of Raw Velocity 

While we are fully aware that Raw Velocity also entails guesswork, the process is better informed. 

• It is an average of multiple developers picking up multiple and diverse items from the backlog and doing the math over several rounds. The average arrived at thus reflects the gut feeling of the majority of your team. 
• Each developer is answering a fairly easier question of how many stories they can complete in an iteration. It’s about their capabilities and not a notional response about a third person. Hence it has more potential for accuracy. 
• This averaging exercise is done speedily–10 rounds with 4 developers each can be accomplished in just 2-3 hours. 
• Since you hide the story points from each developer, you ensure that all possibility of bias is removed. What you get are fresh, original estimates from each developer about the batch in each iteration.  

Call it Estimated Velocity

Since it’s based on guesswork, it is best to call this as “Estimated Velocity”. This is contrary to the definitive sizes we got after the process of Relative Sizing, wherein we recommended to not use the word “estimated”.  

It’s important to bear in mind that just because you guessed a number, it does not entail that that is the only correct number. Hence some of the anti-patterns in this space must be avoided, viz., “Target Velocity” or “Planned Velocity”. These create an impression that that’s the target velocity and those numbers must be achieved. No, you’re just guessing and it’s bound to be different from the ground reality. Let’s just be honest and call this what it is–guessed velocity, estimated velocity, etc. 

Set clear expectations 

With the understanding that this is guessed or estimated velocity, set clear expectations within your team and with your stakeholders. Emphasise that this guesswork will need to be revisited periodically–it’s more of a short-term view. Take a cue from previously completed iterations and incorporate those learnings into the next version of estimated velocity. Staying in touch with reality is what will refine your guesswork and make it more probable. Over time, your confidence about your guesses will improve too. 

Conclusion

To sum it up, the only honest answer to “How fast can this be done?” is “I don’t know.” The next best thing to do is use logical guesswork to arrive at estimated velocity. Furthermore, stay aligned with the real picture and be prepared to relook at this estimated velocity as needed. 

In our next article, we’ll talk about the real show–what happens when you start actually working on the project, what kind of exceptional situations can crop up, and the resultant reactions… Keep watching this space!