Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

Analyze your Value Stream, A Quick How To Guide

clock February 2, 2010 07:16 by author Chad Albrecht

Inspired by Michael Dubakov's article Flow. Discover Problems and Waste in Kanban, I thought I’d spend some time looking at Value Stream Analysis.

We talk a lot these days about delivering value to our clients, but many of us don’t understand the details of how that is accomplished.  Sure we understand that raw ones and zeros couldn’t be sold for the same amount as the aggregated application, but let’s take a more concise look at a couple questions?  1) How do we define value.  and 2) How do we analyze the process by which we deliver value? (Value Stream)

The first question we seek to better understand is the definition of value.  Without diving head first into an economics discussion, we can simply look at value as our client’s perceived worth of the product or service we provide.  This has a dollar figure attached to it.  While one can argue that value is also inclusive of the qualitative aspects of our product or service, it is not easily measured, so for purposes of this discussion can be ignored.  I defined a method of assigning a dollar value to SaaS features in one of my previous posts.  This method can also be used to determine the dollar value of a release, iteration, feature or task on either products or services.  With a dollar value in hand we can begin to look at answering question #2.

As we begin to examine our Value Stream, I would be remiss without mentioning the work of all the people that have contributed work in this area, Eliyahu M. Goldratt, Taiichi Ohno, James Womak, Kent Beck, Mary Poppendieck and Tom Poppendieck, to name just a few.  In Tom and Mary’s book Lean Software Development, they present Tool #2 - Value Stream Mapping which gives us a good way to visually represent our Value Stream:




If we look at the figure above, we see the typical steps that an Agile team may follow transforming an idea into reality.  There is active work that is done on the idea/feature (above the line, value add) and time when the idea/feature sits dormant. (below the line, waste)  Examining the timing of the above hypothetical flow, we can see that the overall process took 18 weeks with 11 weeks (61%) delivering value and 7 weeks (39%) of waste.  This example is a bit far fetched but is meant to provide a simple means of showing how the map works.  You may find it more useful to use days as a unit-of measure or even hours.  The point here being that you may be able to reduce your feature time to market to only 11 weeks if you could only avoid wait time.  If we assume that the feature we are developing will provide $5000 of value in the market, (to our clients) then at 18 weeks we are only delivering $278 of value a week, whereas we hit $455 a week when we do it in 11 weeks.

This can be a very useful tool for improving the productivity of your development organization but we need one more piece to make it effective.  Since we are not developing one feature at a time we need to understand the effects of multiple features flowing through our value stream.  If we only seek to optimize the flow of one feature’s flow we may do that at the expense of others.  We must look at the system as a whole and try to optimize elements that will reduce our wait time for all ideas/features currently in progress.  This is not an easy task.  You should look at the steps that are costly first and try to identify the pain points in those steps.  For instance, if there are days lost because team members are unaware of a status change, seek to implement a tool that sends automated emails on status change.

In summary, here are the steps to analyze your value stream:

  1. Create a map of the steps that an idea takes from concept to delivery.
  2. Measure the value-add and wait time of a number of ideas as they flow through this map.
  3. Assign a dollar value to your ideas and measure your current weekly value and share this with the team.
  4. If changes were already made to try to increase the flow of value, did they work? By how much?
  5. As a team, come up with changes that will increase the flow of ALL ideas through the system.
  6. Implement these new changes and go back to #2.

Prioritizing SaaS Features

clock July 29, 2009 06:14 by author Chad Albrecht

I’ve talked about using your Value Proposition(VP) to rank features by dollar value here and using Ideal Days to estimate duration here.  Now let’s combine the two and look at total value based prioritization of features or PBI’s.  In essence what we are doing is giving the highest rank to features that will yield the most value in the least amount of time.(cost)  To calculate cost we will need some measure of cost per hour.  If you have the actual numbers, use them, if not here are some tools you can use.  Work hours in a year: 2080 Annual salary:  $50K=$24/hour  $100K=$48/hour.  Margin for overhead: 20-30%.  With these tools let’s assume that our team makes on average $90K annually.  This gives us $43 an hour.  Adding 25% we get about $54 an hour.  From here we can simply multiply our cost per hour by our Ideal Hours to get total cost per feature.  Subtract our total cost from our value (sales) and we get the profit per feature.   We then prioritize (rank) by profit.


Feature Rank % of total Value Estimate (Ideal Hours) Cost Profit
8 1 5% $ 4,902 2 $ 108 $ 4,794
9 1 5% $ 4,902 2 $ 108 $ 4,794
2 1 5% $ 4,902 4 $ 216 $ 4,686
1 1 5% $ 4,902 8 $ 432 $ 4,470
3 1 5% $ 4,902 8 $ 432 $ 4,470
6 1 5% $ 4,902 8 $ 432 $ 4,470
7 1 5% $ 4,902 8 $ 432 $ 4,470
11 1 5% $ 4,902 8 $ 432 $ 4,470
4 1 5% $ 4,902 16 $ 864 $ 4,038
5 1 5% $ 4,902 16 $ 864 $ 4,038
10 1 5% $ 4,902 16 $ 864 $ 4,038
12 1 5% $ 4,902 16 $ 864 $ 4,038
16 2 4% $ 3,922 4 $ 216 $ 3,706
17 2 4% $ 3,922 4 $ 216 $ 3,706
13 2 4% $ 3,922 8 $ 432 $ 3,490
14 2 4% $ 3,922 8 $ 432 $ 3,490
15 2 4% $ 3,922 8 $ 432 $ 3,490
21 3 3% $ 2,941 2 $ 108 $ 2,833
22 3 3% $ 2,941 2 $ 108 $ 2,833
18 3 3% $ 2,941 4 $ 216 $ 2,725
23 3 3% $ 2,941 4 $ 216 $ 2,725
19 3 3% $ 2,941 16 $ 864 $ 2,077
20 3 3% $ 2,941 16 $ 864 $ 2,077
24 4 2% $ 1,961 8 $ 432 $ 1,529
25 4 2% $ 1,961 8 $ 432 $ 1,529
      $100,000 204 $ 11,016 $ 88,984


As you can see this moves our prioritization around a little bit.  The nice thing about the above is that we can automate it.  In your Agile Management System each feature should accept a VP rank and an duration estimate in Ideal Hours.  You will also want to have a mechanism to enter the Value of the release, $100K in the example above.  Using these inputs your system should be able to auto-prioritize your features for you.  Now that you have cost, you can track EV,PV and AC on your CVE vs. CVP graph.  I don’t like the PMI term “value” in the EV and PV metrics.  Their old names used to be Budgeted Cost of Work Performed(BCWP) and Budgeted Cost of Work Scheduled(BCWS) which I think is more fitting. Either way, don’t confuse the term “value” in these metrics for revenue.  The value they represent is the cost, i.e. the value of the work.  For this example, we will assume that the estimates were correct and AC and EV are equal, that is, there is no cost variance during the release.  The graph would be similar to that of Figure 1.


Figure 1 – CVP, CVE, PV, EV & AC

I know there are some hard-core Agile managers out there who believe that we should not concern ourselves with revenue estimates.  Some think that simply managing costs while we continue to iterate is enough.  If you are of this mindset, let me ask some questions.  How do you know when your costs are nearing your sales?  How do you determine if your project will be profitable?  If given multiple projects to work on, how do you choose the most important one?

I would also like to remind you that I have not taken risk into account yet, which will again change the priority of the features.  I will try to cover this in future posts.

As always, I would love to hear your thoughts on this.

Value-Based Software Engineering

clock July 27, 2009 11:10 by author Chad Albrecht
Another book to add to the list:
Value-Based Software Engineering
Description from Amazon:

The IT community has always struggled with questions concerning the value of an organization’s investment in software and hardware. It is the goal of value-based software engineering (VBSE) to develop models and measures of value which are of use for managers, developers and users as they make tradeoff decisions between, for example, quality and cost or functionality and schedule – such decisions must be economically feasible and comprehensible to the stakeholders with differing value perspectives. VBSE has its roots in work on software engineering economics, pioneered by Barry Boehm in the early 1980s. However, the emergence of a wider scope that defines VBSE is more recent. VBSE extends the merely technical ISO software engineering definition with elements not only from economics, but also from cognitive science, finance, management science, behavioral sciences, and decision sciences, giving rise to a truly multi-disciplinary framework. Biffl and his co-editors invited leading researchers and structured their contributions into three parts, following an introduction into the area by Boehm himself. They first detail the foundations of VBSE, followed by a presentation of state-of-the-art methods and techniques. The third part demonstrates the benefits of VBSE through concrete examples and case studies. This book deviates from the more anecdotal style of many management-oriented software engineering books and so appeals particularly to all readers who are interested in solid foundations for high-level aspects of software engineering decision making, i.e. to product or project managers driven by economics and to software engineering researchers and students.

The Dollar Value of SaaS Features

clock July 9, 2009 06:27 by author Chad Albrecht

I had a discussion with a colleague yesterday on how to determine the priority of features on a given service. We quickly arrived at the topic of assessing business need, i.e. value, of the features. This is a conversation I've had many times, with many clients and thought it might be worthwhile to document some of my thoughts on this.

If you are building "shrink-wrap" software you can estimate the number of units sold and multiply by the price to get annual revenue. From there you can work backwards to establish your financial metrics. (ROI, NPV, IRR, PV, EV, AC,T,I,OE, etc.) But what about when you are building Software as a Service? This is not a simple question to answer. Regardless of the level of difficulty, it is one that many of us will need to answer in order to effectively grow our organizations. While I don't have a one size fits all answer here, I would like to toss out some tools, ideas and links that may help each of us answer the question for ourselves.

Know Your Value

For starters we should have a good understanding of the value proposition(VP) for the service. The VP will speak to why clients will choose your service over the competition. The VP will look something like:

"For sales teams seeking to reduce time-on-sale by as much as 25% our CRM application will provide full sales process management at half the price of the competition"


"Our internal CRM application will allow our sales team to reduce time- on-sale by 25% and cost only 50% of an off-the-shelf package".

Here is some additional reading:

Developing a Compelling Value Proposition

Stop Coding, Start Marketing! Getting Your Positioning Right

Powerful Value Propositions

Bringing the Value Back Into Value Propositions

In Search of a Value Proposition

Understand the Features That Support Your Value

We add features to attract new clients, keep existing ones, or generate new sources of revenue. We should be doing this in alignment with our VP. We should not be adding features simply because we've conceived of the idea. Given that, we should start by asking ourselves "How important is this feature relative to our VP?" Let's start by using the following 5-point scale for each feature:

  1. Direct VP feature.
  2. Component part of a VP feature.
  3. Compliments a VP feature.
  4. Nice to have.
  5. Optional.

When analyzing the features that support your VP, remember that only 6% of the work on software projects is value added and 64% of all software features are rarely used. (Thanks for the numbers Ryan!)

Price your Value

After you have the VP and the features to support it, you will need to work with your sales and marketing organization to understand what they feel the market will bear, in terms of price, for each unique service. They should also have an estimate on the number of users that will subscribe to the service. Jason Rothbart talks more about this here. Combine this with an innovative monetization model and you have some annual revenue numbers you can work with.

You may also be in a project that has the role of supporting the business. If this is the case, an estimate of the value to the business should still be generated. You may choose to adopt the model that if the service saves the organization 1 hour during a 40 hour week then 2.5% of the annual revenue is attributable to the project. For a $40M company this is $1M annually!!!

If there are no answers to these questions, you may be in the "build it and they will come" mode which is very difficult to generate value metrics from. Try using one of the above models to create an estimate and see how it compares to reality when everything is said and done.

Finally, you should consider what monetization models will be used by your service. Will you only generate revenue from paid subscriptions or will you adopt a freemium model? Will there be paid advertising from within the UI of your service? Are there client stakeholders that are willing to help fund the service? All these are examples of monetization models that will have an impact on revenue and need to be considered as part of the analysis.

Market Lifetime

Given the speed of today's market, including the market lifetime in your analysis is also important. Every service has a limited lifetime due to advances in technology and usefulness to the client base. Typically the market lifetime curves are bell shaped (Figure 1) since full market adoption is not gained immediately and decays slowly due to technology and market pressures.

Figure 1 - Typical Revenue Cycle

How long will your service be able to generate revenue in its current state? 6 months, 1 year, 2 years? If you assume the lifetime to be 2 years and the revenue curve to be bell shaped with the max subscribers in the middle, you can make some fairly good estimates. The answer to this question will play an important part to developing the Value Schedule.

Bringing It All Together

Let's assume that we've determined we will generate $1M over the next 2 years on our service. In order to generate this revenue, we will need to add continuous value and bear continuous cost over the next 20 months. Let's further assume that we will be on 2 month release cycles over these 20 months giving us a total of 10 releases.

Using our 10 releases and our $1M in revenue we can simply calculate the value per release to be $100K. (Ignoring any discounting)

Now if we look at the first release and assume that we have 25 features all of which we have ranked using our 5-point scale from above we can estimate the dollar value per feature. The trick is to normalize the value based on the rank. The formula is shown in Equation 1.

Equation 1 - Feature Value Equation

Using Equation 1 in our example we can now generate a Value Schedule which will give us the dollar value of each feature.

Feature Rank Value
1 1 $ 4,902
2 1 $ 4,902
3 1 $ 4,902
4 1 $ 4,902
5 1 $ 4,902
6 1 $ 4,902
7 1 $ 4,902
8 1 $ 4,902
9 1 $ 4,902
10 1 $ 4,902
11 1 $ 4,902
12 1 $ 4,902
13 2 $ 3,922
14 2 $ 3,922
15 2 $ 3,922
16 2 $ 3,922
17 2 $ 3,922
18 3 $ 2,941
19 3 $ 2,941
20 3 $ 2,941
21 3 $ 2,941
22 3 $ 2,941
23 3 $ 2,941
24 4 $ 1,961
25 4 $ 1,961
    $ 100,000


While not the answer for everyone and realizing I've left out some detail, I hope the tools I've presented here will be useful to you while you are analyzing your next project. I would love to hear what you think!

About me...


I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster



<<  October 2015  >>

View posts in large calendar


Download OPML file OPML

Sign in