Binary Estimation
Estimating work has always been painful for us. How accurately can you estimate the number of hours you expect something to take before you’ve had an opportunity to fully investigate what’s involved? You don’t; you take a SWAG (simple wild assed guess). I’ve always wondered where the value is in that. Pick a date, any date! Pick a number, pull it out of the air — there, that’s our target! I’ve been on way too many projects that use this as their method of estimation.
The first idea to come to light from my training session was that estimations really didn’t matter. In the end, you’re either done or you’re not. It’s simple; binary - 0 or 1, true or false. You don’t get partial credit for being “almost there”. You’re either done or you’re not. So, in the daily scrum where you’re using a board, what you want to see is someone move the tasks they took on the day before from the work-in-progress column to the completed column. Now that’s exciting to me! You can easily see progress, you can see the team stay motivated to make things happen and it’s simple to see impediments. All it takes is breaking backlog items down into tasks that take no more than a day.
No task too large…
Is it possible to break everything down into tasks that take no more than a day? Sure, albeit some backlog items may have many daily tasks, you can still break down what you expect to do into a day. So, at the planning session, you create entries for each day you expect to spend on a backlog item. By striving to be specific in what you’re going to accomplish with each task, you can break a product backlog down. Some tasks will not take a day - that’s fine too. The goal is to break this down into manageable pieces whose completion convey the progress of the team. That way, without much effort, you can get a realistic sense of where a project is at any point in time. Each day, a team member can sign-up for one of those tasks and the following day, they can move the task to completed or identify the impediment which can be quickly dealt with.
We implemented this upon my return and I’ve been very pleased with the results. It’s challenging to get the daily tasks accurate at times, but it’s great to see the team step up and help someone out when their daily task can’t be moved because it’s too big or needs additional definition.
Visualizing Progress with Scrumworks
Where Scrumworks helps with this is in it’s Scrum Details window. What we’ve gone to is a daily scrum where the ScrumMaster opens the Details window. Each team member is then capable of marking those tasks they signed up for as completed or done. With the hours at zero, and the attribute set to not show completed tasks, everything completed falls off the list. Now we can focus on the remaining tesks. These are all “unspecified” for the point person. Each team member then signs up for what they will complete that day. Now, we have a list of what will be done by the next day’s scrum and we have all tasks that remain (the unspecified point person). Simple, elegant, and very meaningful. With the binary system (0 or 1), we can see immediately how many tasks remain which we expect to take a day or less. This is very helpful in determining as we move through the Sprint where we stand in the burn down. Again, a very useful and now easy to see and understand metric!
Sphere: Related Content
