The PROBLEM With Software Development (Episode 2: Story Points)

Welcome to the second installment in the “Solving Software Development” series!

Last week in our first “episode” of our “Solving Software Development” series, we talked about the problems that software development faces in regards to late project delivery and exceeding project budgets. We outlined the “SMART” software development perspective, the solution to the software development problem. Our focus in the previous installment was the first step in this new process, the “S” in “SMART”, which is Starting Small and defining an MVP.

This week, we are going to focus on the “M”, which stands for Measuring Value.

One of the many challenges for product owners and development teams alike is how to measure the value of the work being performed during product development. Many project participants attempt to address this challenge by tracking hours spent on each line item, and cross-referencing those hours spent with a total project hourly budget. Those project participants are making a mistake.

Why would someone measure the value of a produced work by the time spent on the work itself? Do we measure the value of Mozart’s greatest works by the time that he spent in composition?

The idea behind the “M” in the SMART perspective is to measure value by output, by the final result, not by the time spent getting to that result. It seems like common sense right?

So how do you measure development value by output? With a measurement called Story Points.

Story Points were introduced along with the scrum methodology years ago as a means for estimating the size and effort of a certain development undertaking. Story points size up “stories” not by time, but instead by their relative size compared to other “stories”.

What the heck are stories?

“Stories” are usually referring to a certain user ability within a software product, such as a user being able to register with a new account, but “stories” can also refer to development tasks such as spinning up a new server. Basically, “stories” are higher level tasks that a non-technical stakeholder or product owner can understand quickly and clearly.

When reviewing work completed during a sprint, a development team can look at each team member’s velocity (the number of story points completed during a sprint), to get a clearer look at their output over the last few weeks. The team’s velocity can also be relayed over to a product owner, project manager, or client to allow those parties to quickly measure the value of a certain sprint. 

Some development teams even bill their clients by story point instead of by time and materials or by fixed fee. This gives the client the power to accept or reject “stories” based on an acceptance criteria defined before the sprint, and only pay for the actual delivered value and output from the development team. This is actually the way our company, DevelAppMe, bills our clients! This approach incentives the development team to work quicker and more efficiently, while always delivering the client an expected value; a true win-win scenario.

Now, I’m sure that this all sounds great, but how does a development team start using story points when they are used to measuring work by time? 

The first step involves a change in perspective.

In our case, our development team started by changing the way we estimate “stories” from looking at time required to finish a task to a whole new scale. That scale involved looking at two key metrics: complexity and uncertainty.

When our development team looks at a certain “story” during our sprint planning, we evaluate the complexity and uncertainty of the “story”. 

Complexity refers to the number of steps required to complete the story. 

Think about it like walking to a friend’s house down the street for a scheduled dinner. The complexity would be like saying that it is one mile down the street to the friend’s house. It will always be one mile to that person’s house, no matter how fast you get there. One person may run there and get there quicker, and another may walk and arrive later. The friend only cares that you arrive there before their dinner starts.

Uncertainty refers to the level of understanding that the development team has of the complexity of a story.

Going back to the distance to the friend’s house example, uncertainty would be like saying that you aren’t entirely sure how traffic you will encounter on the way to your friend's house. If the level of uncertainty is higher, you may need to leave earlier to make sure that you arrive for their scheduled dinner on time.

When looking at development stories, we calculate the story point value by taking the higher of the complexity the story or the uncertainty of the story. 

This story point approach ensures that a development team always delivers the value to the client, project manager, or product owner on schedule and within budget. That seems pretty SMART doesn't it?

Note from the writer: I hope that you all enjoyed this second installment in the “Solving Software Development” series, and were able to learn something new! We hope to release a new article every week in this series, and would love to hear any questions or feedback that you may have about the SMART software development perspective, scrum, project management, or really anything else!

Also, if you’d like to develop a superior product and not worry about the hassle of doing it yourself, give us a shout!