Unplanned Tasks

While I was implemneting SCRUM in a client, as part of a project management consulting engagement, we discovered he worked under two different delivery models that we deliverately called Planned Tasks and Fires.

The concept was that the Planned Tasks were all the ones coming out from the BackLog and included in the Sprint during the planning meeting, while the Fires were all tasks included during the Sprint itself, without prior planning.

The reason behind this decision was that the client works with initiatives, planned deliveries, commitments done in advance, and –in parallel–, maintenance agreements with a certain amount of hours assigned per month, where tasks were accomplished without any kind of planning.

The initial decision

We first decided to take BackLog Items and transform them into Story Cards, which in turns were broken down into Planned Tasks. This activity was accomplished during the second part of the planning meeting, where all the team breaks them down. While this was done, the TaskBoard was filled with Planned Tasks, placing them in the second column, called To-Do; leaving the first one (Commited BackLog) for the Story Cards.

If there was any unseen maintenance/urgent task not able to wait to be completed during the next Sprint, then, it was inserted in the To-Do column of the TaskBoard as a Fire, in the middle of the sprint.

When to add them?

The first challenge we faced was to determine when those Fires would be added to the TaskBoard. We discussed four different possibilities:

1. At any time: The idea was to add the Fires immediately after they were detected or committed to be delivered. The problem we found with this approach was that adding them in the middle of the day wouldn’t give them enough visibility, what leads them to be known by the rest of the team in the next Daily Stand Up Meeting.

2 y 3. Before/During the Daily Stand Up Meeting: Adding them to the TaskBoard 10 minutes before the Daily Stand Up Meeting or during it to give them more visibility. The issue is that the meeting would take unnecessarily longer than expected due to the discussions triggered regarding the new Fires, instead of using the 15 minutes that were available focusing in the real objective of the Daily Stand Up Meeting.

3. After the Daily Stand Up Meeting: We considered also adding those tasks once the meeting is over to avoid making it too long. What we found out was that showing those Fires would modify the plan for the rest of the day, turning the discussions done in the Daily Stand Up meeting useless.

Finally we decided to follow the first option: “the Fires would be added to the TaskBoard at any moment, just in time”. The way we found to give them visibility was that the member of the team adding them would notify the rest before doing that. A more noisy option I considered was to attach a horn to the TaskBoard in order to get the person adding the Fire using it to capture the attention of the whole room… but for the moment, I’ll keep it in my BackLog.

How to visualize them?

A second challenge to solve consisted on how-to make the different kind of tasks differentiated from each other. Our first choice was a solution posted by Xavier Quesada Allue on his blog Visual Management: leave an empty workstream on top to track the Fires. The post is called Unplanned Items and Legacy Issues. 

After discussing a while, we decided that even though Xavier’s solution would work perfectly in most of the cases, the particularity on this case was that some Fires have certain Buffer that allows other Planned Tasks to be fineshed before moving into them, and we should reflect that.

Finally, we decided to use Post-Its of different colours: Yellow ones for Planned Tasks and Orange ones for Fires, leaving this way the vertical dimension to reflect priority.

Result:

Although in the implementation we found some characteristics to improve (that I’ll address in a later posts, and how we actually solved them) the result was the following one:

1. If a Fire appears, then an orange Post-It should be created.
2. All the team is notified about the Fire before putting it into the TaskBoard.
3. The priority of the Fire is determined against all the rest of the Planned Tasks in the TaskBoard.
4. The Fire is put in the To-Do column, without StoryCard, representing its priority based on the vertical location (the higher, the important).

In practice:

In white the StoryCards, in yellow the Planned Tasks and in orange the Fires: