You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Agile Context Switching

I had the pleasure of trying to work on 3 separate agile projects last sprint. I typically get 40-50 story points done in a sprint. I like to take on more than I think I can do to keep myself from letting work expand to fill time. I also had the issue of having to take on another developer’s work. Total, we promised ~80 story points.

Now, when my kid was new and I wasn’t allowed to sleep nights, I was able to cram 70-80 sps into a sprint. But sleep has made that level of productivity very hard.

I was also tasked with working offsite, organizing a community of practice, and trying to learn a very large project through “osmosis”. Which is to say, learn as much as you can without reporting time spent on it.

I have to admit, all of the work is interesting and the clients are all people I personally don’t want to let down. So it’s hard to say “forget project X”. (Which is hard to say generally when there actually is a project X.)

So with many things pulling me in many directions, my completed story points for the sprint was 33. A significant decrease in general productivity.

Context switching needs to be allocated for in sprint planning. Duh?

The trick is how much? Some people say it takes 15-30 min to effectively context switch. That’s part of it. I think the larger part is when you’re focused on one-two items, you can finish things effectively. The more items, the more you end up with partial work. Partial work is the worst time killer. You get 50% into a feature and if you have to stop and start again it magically turns into 30-40% done.

Solution? Don’t switch contexts.

Har har. Work on something to completion before switching contexts. Be strict about it.

Leave a comment