Tag Archives: Kanban

Sprint Planning and Decision Fatigue

Posted on by
Reply

This article explores the physiological and psychological effects of fatigue brought on by making decisions. The fatigue that comes from making decision after decision immediately reminded me of my team’s Scrum sprint planning days.

The Scrum method breaks software development into iterative cycles called sprints. Our sprints were the highly typical two weeks in length. The idea is that two weeks is a short enough planning horizon that we can pull in enough work from the backlog to fill that time period. Then we demo what we’ve done to the various stakeholders in the company, adjust existing backlog priorities, plan another sprint, and on it goes.

Sprint planning day looked something like this…

9:00 Demos (any stories that haven’t been shown yet)

9:30 Close out the Previous Sprint (closing stories in VersionOne, splitting any unfinished stories, etc.)

10:00 Retrospective (look back over the prior sprint and identify things that worked well that we want to do more of, what didn’t work so well, and identify any impediments to progress)

10:45 Start Sprint Planning (Story Breakdown)

1:30 Finish Sprint Planning (Story Breakdown)

We often wouldn’t finish sprint planning until after 4:30. 

Story Breakdown

Sprint planning is the process of taking the high-level stories and breaking them down into tasks. We did this as a team; so, we had everyone’s input and everyone knew how we were going to go about implementing each story. This is vital to maintaining a team approach to building the product.

This story breakdown, however, is the hardest part of the whole sprint. We have to make decision after decision about how we are going to implement a feature…

Will there be a new database table? Will it be a variant of some existing feature or something new? Is there some new UI element that we haven’t tackled before? and so on.

Then for every decision, we have one more decision: how long do we think it will take.

I believe the hardest part is that we move from one decision to the next without actually doing anything. We are simply adding our decisions to the inventory to be acted on over the next two week. This makes the decision fatigue factor even greater.

By the time we got to 3:00 or 3:30 the team would often be so fatigued that we would start placing two tasks on each story: Plan it and Do it. During the sprint, if we came across a story with a “Do it” task, it was a safe bet that it was planned late in the day.

Remedy

I can see two ways to reduce the decision fatigue that comes with Scrum planning day: 1) reduce the Sprint length, or 2) don’t do Scrum.

For most teams doing Scrum, I think shrinking the Sprint length to one week will reduce the planning day fatigue. Our team, for other reasons, switched to a Kanban continuous flow model. Under that model, we did the story breakdown as the queue of planned stories got low. It was never two weeks worth at one time, and we had fewer “Do it” tasks.

Shifting from Scrum to Kanban

Posted on by
1

My team had been following (more or less) the Scrum process for two years. The Scrum rhythm of biweekly planning, demo, and retrospective with daily stand-ups served us well most of the time. However, we have since shifted to a process that looks more like Kanban. 

The Transition

We had the most friction with the Scrum process after initial releases when our focus turned more toward support and training of our customers. The two-week planning cycle does not accommodate this kind of reactive, responsive work. The dissonance between our stated process and the reality of the work day felt like a process breakdown even though what we were doing was clearly the most important thing for out team. It tended to make everyone a little cranky. Since agile is all about inspect and adapt and choosing a path that gets results, it was time for some adapting.

Our Flavor of Kanban

Unlike Scrum, which has identified creators and a set of doctrines that define orthodoxy, Kanban is more loosely defined. Our idea of Kanban starts with Scrum and and makes a few modifications.

We no longer plan a sprint. We simply pull stories from the backlog as we need more work to do. The VersionOne storyboard gives us a visual of how many items are in each status, and we only pull in a new story if the inventory level are low across the board.

Instead of planning for an entire day before a sprint, we now plan stories whenever the backlog of planned stories is low (less than a few days worth). We still demo the product and hold retrospectives every two weeks.

Since we no longer have sprint boundaries, we needed to make some changes to the way we integrate stories so that we always have a potentially shippable product. We now do all story or defect development on an activity branch in the repository and only merge back to the trunk after it has been thoroughly tested. This creates a bit of new overhead, but we’ve found it worth the effort.

Result

Now we are able to be responsive to new items that come in. The development team feels less jerked around when support issues come in and priorities change. We’d all like to get back to pure product development, but better to face reality as it is than to pretend it is something it is not.