I explained that everything the business lists as a requirement after they see working software we take down as a gap or a bug, then it is prioritized along with the other laundry list of scope items. We have limited time and budget, so the items that are of highest business value will be delivered first, and so on. If the business sees a gap as higher priority than one of the previously identified areas of scope, that’s fine, we take it into account and move it up the list. That way, we are always aligned with what the business deems highest priority.
As I began talking about feature velocity and how we measure it, one of the managers asked, “Yea, but how can we tell how efficient our guys are?” The answer to that question is that I consider ‘efficiency’ a false metric. That is to say, it gives everyone the warm fuzzies to talk about ‘our developers are 99% efficient,’ but when it comes down to it, feature velocity is a much more effective measure of how well your team is doing than how much of their time is utilized.
It reminded me of the “time and motion” studies they used to do to measure worker efficiency
For an assembly line manufacturing environment, this might be a good indicator of factory output if you have a standard number of widgets that a worker creates in an hour. But for software development, it might not be so good of a measure because software development ebbs and flows and has breakthroughs and backtracks.
Ultimately if we see the delta between the team’s estimates and actual decreasing and we have an increasing feature velocity sprint over sprint, that should be all the measure we need to show the process is working as designed and that the team is getting better at delivery. In other words, if it’s a relay race with a team of 6, it’s not the team that is running 100% of the time that wins, it’s the team that masters the dynamics of teamwork and handoffs that is most effective. The team who gets the baton across the line first wins.
The baton is value!