I’ll be Home in Five Story-points

Kent Norman
Manager, Houston Office

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.

Screen Shot 2017-08-24 at 1.22.26 PM

 

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 with Kevin Moormann. Read his bio here. 

More Perspectives

Perspective
by Kent Norman and Kevin Moormann
I’ll be Home in Five Story-points
Perspective
by Kerry Stover
I Know You Believe You Understood What You Think I Said...
Perspective
by Adrian Kosiak
Lessons from Dior on Becoming a Premium Brand
Perspective
by Margaret Rogers
Failing Fast Is Fine — As Long As You’re Failing Well, Too
Perspective
by Allison Esenkova
Wearing Heels to the Top
Perspective
by David Watson
Work Life Balance
Perspective
by Sean McCall
4 Ways Sports Can Benefit Careers
Perspective
by Russell Clarkson
Stand Up for Good Presentations
Perspective
by Sean McCall
Forget Coffee: Energize Your Work Morning
Perspective
By Alexandria Johnson
The Hottest Thing at SXSW You Learned it in Kindergarten
Perspective
by Bruce Ballengee
Developing the Individual
Perspective
by Lori Dipprey
Why Performance Review are Here to Stay at Pariveda
Perspective
by Mike Strange
4 Reasons to Leverage the Power of Small Teams
Perspective
by David Watson
The Benefits of Working in Teams
Perspective
by Sean McCall
The Architecture of a Selfless Team
Perspective
by Nathan Hanks
What it Means to be in the People Business
Perspective
by Bruce Ballengee
Unleashing the Power of Humility
Perspective
by Russell Clarkson
Mark Your Exits
Perspective
by Russell Clarkson
Is your Ecosystem a pipeline or a platform?
Perspective
by Bruce Ballengee
Teaching Roots Run Deep
Perspective
by Samantha Nottingham
Brandsparency: Who Builds Brands These Days?
Perspective
by Dimitrios Vilaetis
Business Capabilities: a Spotlight for Strategic Decision Making
Perspective
by Derrick Bowen
Stop Complaining About Changing Requirements
Perspective
by Tim Hurst
Unlocking Marketing ROI Analytics
Perspective
by Brian Duperrouzel
Hippos and Cows are Stopping Your Machine Learning Projects
Perspective
by Jack Warner
Building Smart Deployment Pipeline
Perspective
by Marc Helberg
3 Ways You Can Begin to Take Patient Experience More Seriously
Perspective
by Ryan Gross
What Does It Really Mean to Operationalize a Predictive Model
Perspective
by Tom Cunningham
The Sound of the Future: Predictive Analytics in the Music Industry
Perspective
by Kent Norman
Limit, to Win It - How Putting Limits on Your Team Will Allow Them to Do More
Perspective
by Sophie Zugnoni
Did You Catch Machine Learning Fever?
Perspective
by Susan Paul
Capabilities as Building Blocks
Perspective
by Susan Paul
When Corporate Culture Undermines IT Success
Perspective
by Margaret Rogers
Identifying the Value of Nonprofit Customer Experience
Perspective
by Margaret Rogers
Why an Agile Mindset is at the Root of an Excellent Guest Experience
Perspective
by Collins DeLoach
What does Cloud Transformation mean to IT?
Perspective
by Mike Strange
Untangling and Understanding DevOps
Perspective
by Clayton Rothschild
Blockchain in an Enterprise Setting
Perspective
by Mike Strange
DevOps: A Practical Framework for Technology Process and Organizational Change
Perspective
by Julio Santos
Context as Currency
Perspective
by Oussama Housini
Why DevOps?
Perspective
by Dave Winterhalter
Data in the Dugout
Perspective
by Mike Strange
Can We Predict the Future?
Perspective
by Julio Santos and Jon Landers
How Customer Context and Smarter Algorithms will Power the Next Level of Experiences and Engagement
Perspective
by Victor Diaz
6 Things to Consider when Choosing a Data Visualization Library
Perspective
<p>by Brian Duperrouzel</p>
Post Cloud and the Lonely CIO
Perspective
by Marc Helberg
How AI Will Affect Your Patient’s Experience
Perspective
by Phillip Manwaring
Let Serverless Solve the Tech Problems You Don't Have
Perspective
by Mike Strange
Bigger is Not Necessarily Better
Perspective
by Sean Beard and Brian Orrell
Life After Mobile
Perspective
by Margaret Rogers
How to Tell the Hype from the Digital Reality
Load More