I love reading articles that question old business processes and point out the fallacy that at one point in time were shoved down our throats as “the way things are.” This article by Michael Dubakov at Target Process is one of my favorite because it involves one of the most cherished tenets of software design: work estimates.
Make no mistake, you have at one point in your career wasted a ton of time trying to figure out how long work you needed to do was going to take.
This applies to a ton of industries, not just IT. My father, who is an electrical contractor, uses estimates to know how much to charge for his services. He needs to accurately know how much his time is worth so that he can appropriately charge for it on an hourly basis when he hands a bill to customers.
Same for developers, although in many medium-to-large-sized companies it is difficult for a developer to know this information. In reality, the financial worth of his or her time may not be valid because there are sales and accounting reps for that. What they do need, is an effective way to take a sprint and cut it into chunks so that work can properly be slotted into it.
In a sense, that is what your time is worth.
Now, as a product owner, it is my job to push the development team just enough to reach for a little more work than they would originally assign themselves. That is the tough challenge of a PO or Scrum Master. We must know when to push and when to lay off.
This is where points comes into play.
With the advent of Agile methodologies, “pointing” a story became the new way to measure the work a team would try to accomplish in a sprint. Over time, this measurement is averaged to calculate the team’s velocity. Just how is this point measurement reached?
Scrum experts such as Mike Cohn recommends taking a list of tasks and assign numbers of the Fibonacci sequence (1…2…3…5…8…13…20…and so on) to come up with your own version of the scale. That way, tasks or stories can be measured for future work. That begs the question of how you know if you are making an informed decision or not.
Is that even possible?
Too informed of a decision means that we are falling back into the waterfall method. Too little of information involved with that decision — what’s the point of having process to begin with?
Measurement must happen in some form, because there’s no way to inspect and adapt if you don’t. The trick to this scenario is deciding as a team (and department if your company has several scrum teams doing work) what is important to making informed decisions.
I’m fortunate enough to work at a company that requires just enough. There are times when the heads of product and project management require more paperwork for work from me, but that’s what I’m paid for. The team shouldn’t have to worry about it, they have great work to put out for our customers.
To be successful, I need software that works. The product line is vast and the requests from our clients are even bigger. We have to get work done effectively, which means spending just enough of our time estimating. Then we can funnel our attention to the tasks at hand, then transparently measure our performance internally and improve.
So work estimates stink, but only when you have to spend more time estimating than necessary. To generate 100% accurate estimates, work become less important than the process. Agile means to use just enough of a framework to be successful and then get out of our own way.
Working software, over excessive documentation.
Blog Post: Work Estimates Stink…Sometimes
Read more "Blog Post: Work Estimates Stink…Sometimes"
Chris Murman 