While reading "The Goal", the author clearly states that there are 3 important measurements in a system ( a manufacturing plant, which can be extended to a software delivery team)
- Throughput - Which in a software project would be the No. of story points actually delivered at the end of the cycle (Iteration or Release)
- Operational Expense - Which in a software project would be the cost incurred (eg: billable consultants, development kit etc..) to actually deliver features (or story points)
- Inventory - Which again in a software world would translate to the number of stories sitting in transition states and not yet customer signed off (Eg: In Development, In QA, On Hold).
The more important point is that one cannot improve on one of these measures in isolation.
Why I say it is important, is because in teams delivering software we often tend to focus on "Increasing the team velocity" without looking at how we can actually reduce the number of "Hangover/In Flight stories".
It is also common for teams to actually sign up for more Story Points in an Iteration or Release in order to show improvement in throughput, which results in more stories in hangover because of some unresolved bottleneck.
Why I say it is important, is because in teams delivering software we often tend to focus on "Increasing the team velocity" without looking at how we can actually reduce the number of "Hangover/In Flight stories".
It is also common for teams to actually sign up for more Story Points in an Iteration or Release in order to show improvement in throughput, which results in more stories in hangover because of some unresolved bottleneck.
One of the interesting things that is suggested here is that Throughput be measured as sales (Rs / dollars). Equating this to story points may be natural but probably inconsistent with the spirit of TOC. Story points, no matter that they are nebulous and a relative measure, are estimated by the people doing the job (devs, qas, etc.). And firmly lands it on the cost side. While it is meaningful to get this estimate, for the purpose of measuring throughput in the context of TOC, we may find "value" estimate by business more appropriate.
ReplyDeleteThroughput would make a lot of sense in a manufacture plant. But not in Software project. One of reasons why software project have not been tagged success is because they have not delivered in value but completed the stories. I think in a software project, measure should be business value delivered for every story or atleast at every iteration. Every business analysis should factor the value to clearly indicate the weight of the story/task.
ReplyDelete