How would you respond to the following question from your significant other, “When do you plan on getting home this evening”? The accepted response would usually be some time measurement such as at 6 p.m. However, when businesses ask agile development teams “When do you plan on getting the new feature done” the typical response is 30, 50, or 973 story points. The confused look on our business stakeholders’ faces is the same as the look that our significant others would have if we were to tell them we’d be home for dinner in 5 story points.
Business Need Commitments and Time is the Interface
When your significant other asks when you will get home and your response is “in 5 story points” he or she is looking for an arrival time. There is an implicit contract where your significant other is expecting a simple, commonly understood unit of measure (6 p.m.) rather than an abstract concept (5 points) that helps you estimate your arrival time from work to home. In fact, if you told your significant other that you were going to gather your mechanic, the local traffic reporter, and play a form of poker that involved a series of numbers loosely representing the Fibonacci series and then come back with a number and that you could translate into a duration but only after you’ve sprinted home a few times, they may just call a Lyft for you, just to be safe. While it may be true that your 20-mile commute could take 35 minutes with no traffic, not in rush hour, or you checked Waze and have to navigate past a multi-car pile-up, and it is always a 50/50 proposition if you will have to stop and wait ten mins at the train tracks. In any case, your significant other expects you to factor those complexities and uncertainties into consideration and reply with a simple “6 pm.”
Estimating in Story Points allow developers a level of abstraction to agree upon how much work the task will take. However, much like our significant others, stakeholders (from product owners up to C-level executives) want straightforward and concrete time-based replies when they ask the questions, “When will we complete feature X?” We have seen situations where IT has missed the mark by not talking in the language of its customers. Part of the Agile Manifesto is customer collaboration, which includes talking to the customer in a language that they understand and not making them learn a new language such as story points. Being able to know a completion date, or being predictable, allows business to make commitments to other parties. In the same way, your significant other wants to know when you will be home in the evening to coordinate plans (dinner, kids’ bedtimes, etc.), the business wants to know when projects and features finish so they can coordinate with their customers.
How to Implement the Time Commitment Interface In software development
Development teams should always give estimates in time to the business, and that usually means abstracting away the complexity that it took to create a date. In programming, we often abstract away the complex details into an interface that can be implemented in many ways. Among the many virtues of this practice is not burdening the consumer of the API with the details and allowing a different algorithm or method to be used to satisfy the request. Similarly, instead of overwhelming business stakeholders with details and encumbering them with the mental math of our converting a 35 point per sprint velocity whereby each sprint is two weeks we can abstract away the details into different estimation implementations. Factoring in the number of weeks in a sprint and the fact that some essential items like bug fixes and tech improvement aren’t “pointed” and therefore don’t count towards velocity but will certainly shift the timeline can become very confusing to your customer. Delivering estimations in time units allows development teams to exploit another virtue of creating an interface, picking the right tool at the right time.
Two tools that are commonly used to reach estimates are story point estimation and Kanban/cycle time analysis. However, just like all tools, it is important to use the right tool for the right job. Using a hammer on a screw or screwdriver on a nail would not be very productive. In the same manner, we need to understand when and where to use user story points and cycle time analysis. While will not discuss the mechanics of using each tool we do provide a framework for choosing which tool to use later in the article.
To know when and where to use these tools we need to understand two key aspects of the environment we are working in 1) Requirements –Are the requirements and objectives concrete or fuzzy. Do you know what to build and what technology to use to build it? If so, you have concrete requirements. If you are being asked to create something vague without concrete requirements, we will call that condition fuzzy. 2)System Stability –Is the environment you are in stable or unstable. Are team members regularly pulled away from their task to work on other items? Are the size and complexity of tasks that you are working on so different it is hard to find any commonality between them. If you meet the conditions above, you are in an unstable environment. However, if you are in a team where you are not asked to change directions often, the team is relatively stable, and the work is broken down into similar sizes then you have a stable environment.
Estimate Tool Decision Tree
Examples
To help us understand when to use each estimation tool, we have created the following list of questions that you could be asked to provide an estimate for the next time you are traveling.
When are you getting home -Concrete/Stable
The best answer to the question is when you have two key assumptions met 1) you have concrete requirements (getting home) and 2) you are in a familiar and stable system (your regular commute). Given these two assumptions are met, you can easily recall past experiences to give an accurate estimation. We believe that using Kanban and cycle time analysis would be advantageous in this scenario. If you were to plot your commute time on a chart over time, you might even notice trends such as your commute on Tuesday afternoon is longer than the commute on Friday morning and will be able to adjust your estimate based on these facts.
When will we get to New York -Concrete/Unstable
In this scenario, we know that the requirements are concrete (get to New York). However, we may not be familiar with which highway to take or how to find the right terminal for our connecting flight to Chicago. In a project context, this is very similar to when a team has done parts of the work separately but have never done all of them in concert. For example, the team may know how to use one technology stack to complete the task, but, the project contexts require the team to use a different technology. In this case, we recommend using story points to help create your team’s estimates.
Dad, I want some food -Fuzzy/Stable
On Saturday afternoons when I am driving around town, running errands with my four-year-old I will often hear the following, request, “Dad, I’m hungry. I want a hamburger”. My son does not care where this hamburger is from he just cares that he gets a burger. In the same manner, some projects find themselves in a situation where the requirements are fuzzy (any hamburger), but the environment is quite stable (I’m in a part of town that I know). In this scenario, we are in the fuzzy/stable quadrant and can use our past experiences to give an accurate estimate of when we will get a hamburger. Because of the team’s experience, we believe that using cycle time analysis would be most appropriate.
In a project context, this would be similar to a situation where we have a stable environment, and we are familiar with the technology, but we aren’t quite sure what we are going to deliver. Landing in the Fuzzy/Stable quadrant could occur if you have a visionary product owner that knows the answer once he/she sees it but often gives vague or ambiguous direction on how to get there.
When will we get to the beach -Fuzzy/Unstable
We can easily see that depending on our choice of beach and mode of transportation the travel arrangements will have various degrees of difficulty. We could be going to Maui or to the sand bar at the local lake that my four-year-old son calls a beach. Better yet, we also do not know what mode of transportation or system we are going to use to get there. Are we going to go by car, plane, Segway, or some other mode of transportation? In IT shops, we are often put into similar situations where the destination is ambiguous and the process to get there is unproven. Often you come across this situation when a new project starts. When the goal is vague and the environment unstable, we recommend creating a proof-of-concept (POC) deliverable. By developing a POC, you can begin the journey without committing to going all the way. This way you and your team will be able to identify potential trouble spots before you embark on your new journey.
Conclusion
Whatever you choose for your internal team estimates, find a way to translate the estimate to a time measurement when communicating with the business. Remember time is the interface. Allow for a point estimation for complexity. However, try to get to cycle time analysis as soon as possible to give a delivery date. The point is your communication outward should be in time even if you use story points or whatever else to estimate your time internally.
Published by Kevin Moormann
Connect with me on LinkedIn
