Scrum methodology seems to conquer the project management in IT, outmatching classic waterfall solutions. While being agile, flexible and closer to the goal through the process, it’s easy to lose track of the agile manifesto.
One of the basic pillars of scrum is planning. By definition, it is an event in the framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing backlog items.
I’ve seen scrums you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near.. oh wait, it’s not this kind of dark fantasy.
Let’s see how to make the scrum meetings more meaningful!
Breaks!
Classes last 45 minutes for a reason. People have limited attention-span, which seems to deteriorate moderately after three-quarters of an hour. Usually, planning process takes between four to eight hours depending on the length of the sprints, divided among the first week of the cycle. Even, when a single meeting takes more than an hour it’s worth to take a break and switch context for a while. Planning can really be a demanding process.
Stay away from the screen
Whenever possible try to avoid dial-in meetings in front of the screens. Fellas in IT already spend too much time sitting. Going out somewhere, let it be the conference room, can increase the team dynamic drastically and encourage conversations. On the other hand, starring at a 2-hour presentation of some business domain logic implementation can really be a mind-numbing experience…
Immediate feedback
When a team discussion arises and there are significant differences in estimates, the gap needs to be addressed immediately. Usually, new team members tend to overestimate for obvious reasons, but maybe the variation derives from the knowledge of an experienced colleague of a reusable component?
Estimation tools
…don’t really matter (cards, colors, t-shirt sizes), but have to meet the following criteria: be handy and consist of exponential values range. Why? Is there a significant difference between 22 and 24 hours estimate? It’s a truism. Estimates are always wrapped with a statistical error, so make it quick, easy to use and intelligible.
Goals and priorities
These two are slightly overused buzzwords, however I can’t stress enough how helpful for me it is to have a clearly defined task priority. Team should determine what it wants to achieve after the sprint. Being aware of the core responsibilities in a sprint reliefs a lot of stress . This also helps developers to pick up tasks in a prioritized way. Instead of dividing the workload among developers, it’s a good idea to create a dynamic queue. Additionally, making a reasonable bet about the sprint priority helps to avoid an evergrowing backlog. Everything that wasn’t done in the sprint, goes to a backlog, no sprint extensions.
The How
After the basic requirements for the task are described, it’s worth taking a while to talk on how to design the solution from the architectural standpoint. Don’t go into the implementation details, but agree on a high-level layout. It’s also worth to discuss the pitfalls and strong points of the solution and bang them against the business requirements.
Creeping Death
My humble opinion is that tasks estimated for more than 2 full days of work should be divided into smaller bits. The reason is that often these tend to “creep” and inflate as the process goes on and it’s difficult to close them, or in other words, meet the ‘definition of done’. Describing a task in a way that would be reasonable for developers is not as easy as it seems, as some surprises may come up on the fly. The bigger the task, the bigger the chance that it’s going to expand even further, because someone has a “a great idea” or has simply lost some details in the description… Meanwhile, smaller tasks are more easily trackable, countable and create a pleasant illusion of quicker progress.
Velocity
Last but not least, measure the number of completed tasks and their sizes to better define the priorities and core functionalities for the next iterations.
