Maximizing Value by Minimizing Waste

There are many factors to consider when architecting a software solution. The architect may design the solution to be built in Java using an MVC pattern. Managing the project using an agile methodology, the project has clear user stories with a well-defined backlog. The team has worked together to determine appropriate technologies to incorporate – JMS for asynchronous messaging, Oracle database, and nHibernate object relational mapping. With these in place, many architects believe the way to deliver further value to the client is to design solutions to current problems that anticipate future requirements. I contend that this may not deliver the most value to the client in the long term.

Let’s assume we have a user story that reads “As a user, I want to be able to access biographies of employees, so that I can decide if the firm is one I’d like to hire.” Let’s further assume that the acceptance criteria are as follows:

  • Biographies of 5 employees: Terry, Sue, Mike, Tom and Helen
  • List of employees
  • Page load of less than 1 second

In meetings discussing the backlog, the product owner mentions that it would be nice at some future point in time to be able to add additional employees and edit the biographies. When pressed to add those features as acceptance criteria, the product owner says “I know we’ll eventually do it, but I’m not sure when.” Stories are added to the backlog to add employees and edit their biographies, but not as part of any planned release.

When estimating the story the team discusses different approaches to the problem: creating a static html list and static biographies or creating a table in the database to store biographies and display the contents of the table. The team can’t agree on the right approach, so they estimate the effort of each approach: static: 1 effort point, database: 5 effort points. How do we decide which implementation is right? Historically, we as developers would typically choose to store the data in the database.
 
The application can play out one of two ways: you either eventually implements some of the editing features or you don’t. If you assume it’s a 50/50 chance that either could be true, let’s look at the effort wasted. If you choose the database approach and you don’t implement the editing features, then you wasted 4 effort points. If you choose the static approach, and you do implement the editing feature, then you wasted 1 effort point. This assumes an even probability for each outcome.
 
What if you assume a 70% likelihood of implementing the editing features? If you choose the database approach and you don’t implement the editing features, then you wasted 4 effort points * 25% likelihood = 1 effort points wasted. If you choose the static approach, and you do implement the editing feature, then you wasted 1 effort point * 75% likelihood = .75 effort points wasted. The break even on this scenario is at an 80% likelihood of implementing the editing features.

While definitely a contrived example, I think it clearly illustrates the importance of minimizing the effort to deliver the value for the user story at hand. Considering potential future user stories can lead to wasted effort. Every choice we make involves potential waste. Building your solutions in an attempt to anticipate future user stories may result in wasted effort. There are many more variables that come into play when trying to determine if a future story will be implemented: lifespan of the application, changing customer demands, changing stakeholder priorities, economic downturn, etc… These factors make it difficult to judge the likelihood that a potential user story will ever see the light of day. I think it’s time to take a hard look at the value of building flexible solutions that anticipate the future and consider maximizing value and minimizing waste.

Your email address will not be published. Required fields are marked *

Phone: 312-602-4000
Email: marketing@westmonroepartners.com
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons