AAA Toolbox: Pomodoro Story Sizing Sessions
09 Apr 2012Esse é um post de uma série que eu compartilhei internamente na ThoughtWorks uns anos atrás. Eu escrevi em inglês, então republico assim, mas se a série acabar sendo bem popular, eu prometo traduzir tudo.
Estimation. Just the mention of the word can make developers roll their eyes and even question why bother altogether. Indeed, estimations are usually hasted guesses based on shaky assumptions. JK Werner advocates that we shouldn't even call it estimating, as this frames the thinking into cost and time, when this type of analysis can only be attempted when we add a predicted velocity to the relative sizes of stories. What we usually do in estimation sessions is actually simply relative-sizing stories.
The debate about this activity usually revolves around the trade-off between waste of developers time vs. project predictability. For me this misses the point. In my opinion, the real value of sizing stories lie in the time-boxed discussion about the specific implementation of stories and the identification of the challenges and risks of a project that come up in these conversations. Many times, important design decisions are evaluated for the first time in story sizing sessions and this allows the delivery team to avoid spending time with impractical solutions. The resulting sizes may be an educated guess, but are merely one of the outcomes of a valuable activity.
Of course, there is still the problem that sizing can take time and, quite honestly, be boring. To be effective, sizing sessions should be a high-energy affair. This can mean the cheap thrill of coffee and cake (good to bring developers in to the room), but ultimately it requires some preparation so each story is well understood by the Business Analyst and it is introduced in a quick and interesting way. It is important to keep it snappy. In order to save some time, it may be possible to group stories about the same subject together. It avoids repeating the context every time, but, in the other hand, can create big dependency chains since developers tend to assume other stories of the same group have been played.
To keep the energy at a high level - particularly when estimating big batches of stories - it can be good to use "Pomodoro Sessions". The idea is to use concepts of The Pomodoro Technique to break the effort in constant intervals and work trough the story list this way. You can break a 2-hour time slot (the usual time of a inception session) into 25 minutes - 5 minutes break - 25 minutes - 10 minutes break - 25 minutes - 5 minutes break - 25 minutes (or the reminder of the 2 hours). The reason why the last session duration can vary is that some sessions (or breaks) may overrun. Sessions will naturally overrun because it is not productive to break discussions when the 25 minutes are up (in fact, it can be a real energy killer), so you probably want to finish discussing a story (and estimate it) and then go into a break. People tend to wander off and get distracted during the breaks, so be prepared to get everyone committed to come back on time and harass people if they don't.
Having pomodoro-sized sessions allowed developers to be engaged by removing the anxiety of an endless session. It helps in cases where you need to bring particular people only for some specific stories, or when you can't keep the same group for the whole time. You can also track how many stories the team averages in each interval so you can actually know how many you will need to get trough a batch of stories. As with anything, use judgement about when to Pomodoro: Do not hesitate to have a longer session if energy is high and the team is particularly focused. The important thing is getting the end result of engaged developers having meaningful discussions with the least possible waste.