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 tasks. 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!
Your take on Scrum is spot on! but please understand that Scrum itself isn’t a complete Agile Practice, you have to supplement Scrum with other practices as well so as to encompass all four principles of the agile manifesto.
For instance the most common (i wouldn’t use the word best) combination of Agile practices used around the world are Scrum+XP. Both on their own are partially complete, but together they compliment each other’s strengths and cover up each others lackings.
Scrum only helps you bring discipline into your development process and tries to identify weaknesses early so that you can improve on them, but it doesn’t claim to give you a road map to good technical design or good continuous integration methods. It’s not supposed to do that, and it doesn’t do that. In order to improve your development techniques so as to remain Agile AND at the same time maintain quality you should look into other practices that really address these issues. There are 22 different types of code smells that one should know of. One should also try FDD and TDD and really see how well defined and helpful these are for agile development.
All in all, sticking to the premise of your entire article, you’re right, two days of training would not make you a ScrumMaster. And even if you do become a really good ScrumMaster, Scrum does not guarentee… nay… claim that it would instill good programming ethics in your developers.
My two cents worth.
Thanks.