So, this story point thing... what's up with that?
When estimating effort for user stories most people use either ideal hours or story points. My recent experiences have been with ideal hours. This works well but there has always been something that keeps me thinking about the value of using story points instead. I've never used story points but I'm increasingly feeling that there is a lot of value and an ability for them to help shake some teams free from rigid past behaviors. Is there anything wrong with ideal hours? Not that I can tell, but I do believe there might be some negative behaviors at play for organizations that are moving to agile software development from more traditional methodologies (e.g., waterfall, etc.).
What "Is" An Hour?
In release planning, teams typically arrange stories based upon some priority which may consider customer value, time to market, effort, etc. Stories are slotted into a release with the release being delivered after a certain amount of sprints have been completed. The number of stories that fit within a release is determined by the team's velocity. Velocity can be measured in any unit but often is represented in points or ideal hours.
If ideal hours are used to estimate story effort then it is really easy for people to equate these to "real" hours. It is a hard behavior to break. Hours and ideal hours look frighteningly similar. Might someone interpret a 40 ideal hour effort to be something that can be completed in one week? Please tell me you understand why this is not the case.
I have no proof, but might the use story points begin to break this connection to real hours. Since story points are a relative measure of the time needed to implement a story, there is no real connection to hours.
What's My Velocity?
Regardless of the unit being used to estimate stories, a team will stabilize around a certain velocity. Velocity representing the amount of work a team can complete in a sprint. There will certainly be some fluctuations in velocity which may be caused by holidays or an increase in support activities, but in general, a team will stabilize. One other item to note is that there is usually a difference in velocity across teams. For this reason, velocity is NOT an appropriate measure of productivity.
Where Did The Time Go?
At release planning, each story is estimated using points but once sprint planning is done, the team will use hours. Each story is split into some number of tasks representing work to be done for the story. The detailed tasks are estimated using hours and the team can then determine if they can complete the story. When the sprint planning meeting ends the team has a committed set of stories for the upcoming sprint.
Are We Done Yet?
Each team, and others, are interested in tracking progress during a sprint. Story completion seems like a good measure but often stories are closed at the end of the sprint with the customer which doesn't really help during the sprint. Since the stories have been broken down into tasks, the completion of tasks provide a good indicator of progress within a sprint. Most team members will update tasks, work done and work to be done, each day. Some sprint planning tools will use task completion and remaining work information to create a burn down chart which shows how well the team is tracking against their sprint commitment.
At the end of the sprint, the number of story points completed is used to determine a team's velocity. Story completion is the real measure of delivering value to a customer.
My initial purpose for writing this post was to try and discover for myself the benefits of using story points. In doing so I've highlighted common practices of release and sprint planning, certainly not in detail. At this point, I do believe there is greater value in using story points rather than ideal hours. My thinking is colored by my experiences and the type of organizations I've worked in so your mileage may vary. If you have an organization that is moving to agile software development that comes from a place where the norm included big requirements up front, lots of design up front, massive Gantt charts prior to project start (the plan is always right, right?), and similar dysfunctions then the use of story points might assist in the change. You might find that the use of ideal hours creates too strong of a connection to past behaviors. Story points are not a cure-all and will not eliminate unhealthy behaviors but they do cause a shift in thinking that can't hurt.
I'm game to give it a try.
How often do you really take a look at the amount of work in process you have going on? I often find when I stop to do so I start to understand why my arms are so tired… juggling balls is hard work! Too much work in process will destroy your productivity even in the midst of being so busy. Busy does not always equate to productive. Context switching exacts a terrible cost and it can easily consume 20% of your productivity if switching between 2 or 3 tasks. The same personal productivity thief is found in many business when everything has to be done, now!
When developing software there is a focus on providing high value features to our customers. If we reflect upon the challenges of context switching we might choose to focus on one feature, complete it and potentially deliver it to our customers before moving to the next. More often than not, all of the features are deemed must haves and we are asked to develop them together thus creating a context switching problem which increases waste and reduces our throughput. This figure illustrates this concept.
As you can see if we focus on feature A, then feature B, then feature C we can deliver all features within a three month timeframe, in our example. In addition, we are in a position to deliver the value of feature A in a month's time and feature B in two months providing value to our customers and revenue for us.
If we choose to work on all features at the same time then we've created a situation where no feature is deliverable until 3 months pass. Worse, because of context switching overhead, we won't be in a position to deliver even these three features until almost 4 months pass (using 20% overhead for context switching). This causes a substantial cost of delay over the first example. This cost of delay impacts revenue and customer value. In the first model our customers begin to benefit as soon as one month which is 3 months earlier than the second model.
This is an oversimplified model but illustrates the dangers of context switching and the value of limiting work in process which I'll write about in an upcoming post.
I've lately had a number of conversations with colleagues on the frequent disconnect between IT and the business. Does business look at IT and say, "are you talking to me?"
As my friend and colleague Brian Sondergaard (http://blog.softwarearchitecture.com) likes to say, we create this situation and we do it to ourselves. We do this because we believe that it is the technology that is important. Technology isn't necessarily important to the business. Sure, technology provides tools capable of creating business value but when they don't, they are not terribly interesting to the business. Using these technologies to provide business value? Now you'll get the business's attention.
We have to shift our language and understanding of the business. We must have a clear understanding of our business goals, communicate them to our teams, and have business discussions with our customers. When we start to understand and speak the business we are equipped to understand what is important and how we can use our skills to deliver software that increases revenue.
Creating strong ties to business goals creates clarity for what each of us must do to support the business. Business goals must be the rallying cry for aligning our teams. Every activity we perform should pass a litmus test of providing business value.
If we do this then we'll see that the business no longer sees us as a cost to be controlled but as a partner that understands how we can use and create technology to meet the goals of the business. I would much rather see the business as a partner and not one that doesn't understand the creation of business value.
Unfortunately, it seems to be difficult for companies to actually create an innovative culture. One where creativity is fostered and expected at all levels of the corporation. Companies that truly innovate tap into the creativity of each and every employee. They strive to enhance the creativity that exists in each individual.
We all enter this world with a vast amount of creativity. Think about your childhood and the how creative you were. Did you make up silly games? Did you tell fanciful stories? Did you sing, draw, dance? You were a very creative individual.
As we enter school, and eventually the workforce, the "system" strives to extinguish that creativity. We must become similar, we must not deviate outside the norm, we must comply. What a dull and uninteresting world we are creating. Corporate America seems to have perfected this ability to create a workforce of sameness. Training programs and rating systems are created to ensure everyone is molded into the same corporate citizen, much like the Stepford children.
This can be reversed! We can find and unleash our creativity! Why? True innovation is born from a thousand ideas. Creation of thousands of ideas is not the domain of the few. Thousands of ideas are created by fueling creativity across all employees. It is from these thousands of ideas that we find the game changers. It is the game changer that catapults profits.
Why then do we not unleash the creativity bottled up in every employee? There are many barriers but one is that change will upset the status quo. When every employee becomes a creative force then why do we need to have jobs specifically for creativity? Often these areas of the organization feel it is their responsibility to monitor for "unauthorized" creativity. They then fell a responsibility to maintain the status quo by dousing the fires of creativity that threatens their existence. Dousing creativity which is exactly what we need to foster in our companies.
My advice, as a good friend of mine likes to say, nurture the freaks.
- Encourage creative thinking
- Encourage people to bring non-work skills and passions to the workplace
- Encourage people to foster their unique strengths
- Encourage people to step outside of job descriptions
- Encourage people to have fun
- Encourage people to resist compliance
Have you ever been in a situation where you have not gotten enough sleep for some period of time? At some point you are able to sleep normally again which does wonders for your recovery. In times of extreme exhaustion we might want to sleep more than a normal amount. We believe we can make up for our earlier deficit of sleep. As my wife is fond of saying, "you can't catch up".
In fact, sleeping too much in an attempt to "catch up" can exacerbate the situation. There are a number of studies that show too much sleep can lead to increased anxiety, mood swings, and continuing to feel sleepy throughout the day. What seems intuitive is not.
Similarly, the same "catch up" behavior often occurs in software development. I've heard more than once in my career something like this - "we have some extra bandwidth with our business analysts so we're going to "catch up" on requirements. We can get enough done so that we will be 6 - 8 months ahead of development".
I hope most of you agree that this is wrong thinking. Do you agree that this is not an optimum approach? Why do we fool ourselves in behaving this way?
What's The Big Deal
Software development has inventory just like any other organization that produces something from raw materials. It is very difficult to see that inventory. Just ask your company how much inventory do they have and I'm sure you will get a questioning look or a statement that there is no inventory in software development. Any work we do that produces output (e.g. requirements documents) results in inventory. Requirements are just one example. What other examples can you think of?
Why is this inventory bad?
Uh Oh, It Is No Longer Fresh
This analogy may break down but why do grocery stores not stock their shelves will months of inventory, say bread or vegetables? Those products must remain fresh to provide value to the customer. If they are no longer fresh then they must be thrown out and that is waste.
Continuing with the requirements example, they too must remain fresh. Do you believe that requirements created 6 months before they are acted upon have not changed and are still "fresh". Not likely and in fact, some of those requirements may no longer be relevant. You'll either have to rework them or throw them out and that is waste.
Focus On The Constraints
Software development creates a variety of output needed to build functionality delivered to the customer. The process of software development creates inventory which has a real cost. We operate under a model that seeks to keep all resources at maximum capacity. We believe creating something is the higher order goal and we don't recognized the potential waste.
The Theory of Constraints would show us that our focus should be on eliminating bottlenecks in our development system. This is a very different view from what I've described and it implies situations may exist where we do not maximize output in all stages. This is NOT how most companies operate and that focus on maximizing resources unwittingly causes dramatic increases in unseen costs.
Be careful about "catching up", it can be a very expensive proposition and not one that provides value to your customer in the most efficient manner.
I'm absolutely captivated by this area of study and have more to say. If you would like to learn more then I would recommend the following texts:
Does this look familiar? Someone comes up with a new idea. That idea is shared and has promise. It is then sent up the "chain" where it increasingly meets resistance. More often than not, it is killed. Why?
- It is too different from what we do today
- We don't have resources that can be taken off "approved" projects
- It would take too much time and expense to prove that the idea could be profitable
- It didn't come from the group that is responsible for new ideas...
- ► 2009 (9)
- ► 2008 (9)
- Rick Austin
- Software development professional with a passion for the people side of the equation. Yep, technology is fun but it is people that deliver.
Steering committee member of the AtlantaMINIS which is a side effect of my maniacal passion for MINIS :)
Musician performing in an alternative rock band doing all original music.
Photography is yet another passion which I participate in every day. I have to, I'm in a photo of the day club :)