Timespace management

SCRUM: the final frontier. This is the voyage of AnythingButEnterprise. Its continuing mission: to explore strange new worlds, to seek out new forms of efficient and pleasant work, to boldly go where no company has gone before.

This post concerns the planning of SCRUM Events. The sponsors of today’s episode are timeboxing, understanding above orthodoxy, and a breather.

Timeboxing

I believe timeboxing to be something more than just the empirical theory of process control and empowerment: it is one of the pillars that SCRUM is standing on. The need of strict keeping to the timeframes simply radiates from the pages of SCRUM Guide describing SCRUM Events. Yet, I noticed that majority of teams beginning their adventure in the galaxy of SCRUM, as a rule, ignore the principles connected to keeping to the agreed timeframes. I must honestly admit that it was so also in the case of my first “agile” team. Novice teams in most cases try to maintain regular length of the sprint at the same time forgetting that the time constraint holds also for other events, notably Sprint Planning, Daily SCRUM, and Retrospection.

Holding meetings within the timeframes often happens to be much more difficult than it is in the case of Sprints. What you find below are a handful of suggestions that I hope could be helpful in your management of the difficult art of timeboxing:

• Make an agenda for longer meetings, accounting for the maximum duration of each item on the agenda – this is where you exploit the profits of the divide and conquer strategy (should you of course keep to the timeframe of every item of the agenda, you’ll hold the timeframe of the entire meeting without skipping any item as well); this is especially useful while running retrospections.
• Pay attention to punctuality, always start meetings on time; if somebody is still not there – tough luck: don’t wait for them, but explain the issues with the “delinquent individual” after the meeting. Why waste your time?
• Put “an egg timer“ in a visible place during every meeting. A clock does well, but a stopwatch or a timer works much better. As an aficionado of Apple branded devices, I use the 30/30 app. It lets us measure how much time is left for a given point of the agenda. I don’t think it’ll take much time to find an analogous application for other platforms (Android, Windows, LINUX).

What happens if you “haven’t made it” by the time designed for the meeting? Well, if it comes to that, I suggest that the last 15 minutes are devoted to:

–  wrapping up what you have managed to agree at the meeting

–  precise settlement (best in a checkbox form) of what you did manage to agree at the meeting

–  making the decision whether it’s worthwhile to continue discussing the questions you haven’t yet solved; and if it is, then:

• agree precisely on what still remains to be agreed (defined the purpose of the additional meeting)

• agree the timeframe of the additional meeting

• agree when it is to be held (of course it can start immediately once the current one has ended, and become a practical extension of a kind).

Yet, remember that any additional meeting is held at the expense of something else. If, for example, you need additional two hours for Sprint Planning, this means that you will have two hours less for the work proper on the Sprint. Make sure you took that into account while planning the volume of work you want to cover in that sprint.

SCRUM master should set the holy adamant example in the matters of timeboxing. It is out of question for the master to be late to meetings or to extend them.

Agile SCRUM

Now I wanted to focus on the overzealousness, shown by certain SCRUM purists. SCRUM guide defines no strict time frameworks for vents. Let us for example take a look at the question of Sprint Planning. The quote below is a verbatim translation of an excerpt from the Polish translation of SCRUM guide by Tomek Włodarek: “Sprint Planning is an event limited to 8 hours for a one-month sprint. For shorter sprints, it is as a rule, shorter”. What does this say? SCRUM guide defines the maximum duration of the meeting. It does not impose but suggests that in the case of sprints running for less than a month, a Sprint Planning should last no more than eight hours. I have often heard and read that a team that runs fortnightly (two-week) sprints and devotes three hours to their planning accused of doing a “SCRUM-butt”, as it should only devote four hours. This obviously is balderdash. Be “agile”. Adjust the duration of SCRUM Events to your actual needs.

For “fresh” and SCRUM-inexperienced teams, I suggest recalculation with 1:1 ratio. This means:

an 8-hour Sprint Planning for a 1-month long sprint (4 weeks)

a 4-hour Sprint Planning for a fortnight’s sprint (2 weeks), and

a 2-hour Sprint Planning for a week’s sprint (1 week).

Read also: How Scrum Can Boost Your Team’s Productivity

Discuss the efficiency of Sprint Planning at the retrospection after every sprint. If you can’t fit into the defined timeframe, look for solutions that will increase the efficiency of the meeting. Make the decision to extend Sprint Planning (if there is need) only after a handful of sprints, once it has transpired that – despite the changes introduced after the retrospection – there is still a problem with completing your Sprint Planning on time. The problem is that teams often “choose the easy option” to increase the duration, while the true problem lies in the low efficiency of the meetings.

Let people rest

The environment where developers feel best is obviously the programming milieu. 😛 Most of them consider meetings a form of necessary evil. Planning SCRUM Events, make double sure that the concentration of meetings on a given day does not exceed the lethal dose. There was a time in our team when Sprint Review, Sprint Planning I, Sprint Planning II, and Retrospection were all held on the same day. In result, people were absolutely fed up during Sprint Planning II already, and Retrospection (held at the very end) might attract three participants.

That’s why:

•  After every 1.5÷2 hours of the meeting plan a 30-minute break.
•  Arrange lunch break at a specified time, especially if people order food. If you don’t, the meetings will regularly be interrupted midway, as “food has arrived”.
•  It’s a good practice to spread the events closing and launching the Sprint (Sprint Review, Sprint Planning, Retrospection) over two days.
•  The days spent on planning should not exceed 8 hours, although I personally recommend that they are shorter. We’ve got far more significant things to do than “making sure we’ve sat for a full day”.
• An attempt at “saving” time on SCRUM Events by their maximum “stacking” in the timetable is more likely to bring adverse than expected results. The tiredness of team members will certainly have a negative bearing on the efficiency of the meetings, their creativity, level of initiative, and quality of plants.

Read also: How can you use metrics to measure your team’s productivity?

Our (typical) agenda

This is what our team calls a typical agenda:

Tuesday

9:00 – 10:30am   Sprint Review

11:00am – 1:00pm   Grooming I

1:00 – 1:40pm   Lunch break

1:40 – 1:50pm   Kudos meeting

1:50 – 2:00pm   Doomsday clock meeting

2:00 – 3:30pm   Retrospective

Wednesday

09:00 – 11:00am   Grooming II

11:30am – 12:00pm   Sprint Planning I

12:00 – 12:40pm   Lunch break

12:40 – 3:45pm   Sprint Planning II

3:45 – 4:00pm   Sprint Planning – Summary

A handful of comments on the above:

• Due to the team size (what we call) planning days lasts for two days.
• The team decided to include Grooming into planning days, to focus on the actual execution (development, testing, deployment) during the “Sprint proper”.
• Between the meetings (lasting up to 2 hours), the team has 30-minute breaks.
• During Sprint Planning II that is a little bit longer the team is making short on-demand breaks
• The lunch break is 40-minute-long. It is agreed earlier, so that everyone knew when to order food. Without it, meetings were often suddenly interrupted, as lunch was delivered (at random times) and had to be eaten while warm.
• During Sprint Planning II, the team splits into sub-teams, with each defining their own breaks.
• Sprint Planning I is very short (30 minutes) and serves general discussion between the team and Product Owner on which User Stories to cover in the sprint. This is also the time for the development team to fine tune the questions about whatever interests them.
• Sprint Planning – Summary is actually a fragment of the second part of Sprint Planning. It has been separated as the Product Owner often participates in SCRUM Events remotely (our product is for a foreign client). During the wrap-up the developer team meet the Product Owner in a video conference to arrange the final shape of the sprint.
• The timetable covers 7 hours rather than the standard 8. The reasons behind it are:

• members of the team arrive earlier on Tuesday to get the environment (servers, applications) ready for Sprint Review

• there are plenty of planning meetings on Wednesday, and towards the end of the day “brains are oozing out through people’s ears”.

PS: The title was inspired by a certain requirement that I saw (thanks, Darek S.) In a TOR document for a public tender. It read: “the system should manage timespace.”

This only reinforced my conviction that only agile “methodologies” are capable of saving the IT component in public procurement. I am shattered by the amount of money we have toiled to earn going down the drain.