Brian Hartsock's Blog

Today, I interviewed a developer/team lead who had a very similar first experience with Scrum. Not very surprisingly, it matched my own so I thought I would share.

The terminology sucks

Two years ago, when Scrum was first proposed, I remember I hated the terminology. Sprint? Backlog? Scrum? Story Points?. It is like a mixture between a sport and fantasy novel. Back then, I liked terms like requirements and project plans. The interviewee had much the same thoughts as me.

My advice, don’t let it be a barrier to entry. Change the names if you want to match your current process initially. (Although I think the names are important because of the mental models they build)

Plan with Scrum, work the same as always

When the interviewee said this, I knew exactly what he was talking about. It isn’t a bad first step into Scrum, but it causes some pain. Handing off to QA after a sprint starts to break down over time. You aren’t working on the most important things first. Etc.

The good thing about Scrum is it doesn’t claim to be right. It claims to be a flexible foundation which will get better each iteration. As long as you are changing the process every sprint based on the pig’s feedback, you will get the process where you want it to be.

One interesting observation I have seen regarding Scrum at Rackspace Apps deals with task breakdowns. Breaking down a story from the product backlog is an important step to create the sprint backlog. Breaking things down into smaller pieces is going to increase estimation accuracy, as well as help the team understand all the different parts of a story.

But tasks don’t mean anything. The story is the functional piece of software the product owner requires, not any individual task. Tasks only serves as a compass for a team to track progress during a sprint. It is important to remember this and not become obsessed with task breakdowns.

With that said, how should teams go about breaking down a story into tasks? How granular should they go? Well, all teams are different, but I think I have found the general rule that works well

You are too granular when the team starts talking about the invalidity of tasks during a sprint.

Just this week, I had a team discussing how most of their task breakdown was not valid near the end of the sprint. It ended up that the story had about 3 tasks, not 6. When this starts happening to teams regularly, they need to take a step back and get less granular. Invalid tasks are a waste that should should be eliminated.

The general Scrum recommendation is 4-16 hours per task, and I definitely see anything under 4 as usually a waste. I have some teams where their breakdown is 2-3 days. It seems high, but in the end, if they are getting their stories done at a regular pace, it is fine with me.

But then again, do you even need to estimate tasks to begin with?

Over the past few months, I have been working a lot on release planning for my teams. Not only have I seen the light on its importance, but it has also helped me realize problems with my own prioritization. Each time I change my release roadmap based on additions/modifications to the backlog, I realize how hard planning for the future is.

My solution, the Volatility Factor.

Here is the scenario. You have a team with a velocity of 15. In doing their release planning, you have the next three sprints planned out. After the first sprint planning, the roadmap hasn’t changed. By the time the second sprint planning roles around, the backlog has changed by 5 points. Maybe a large scalability issue was encountered, or your largest customer requested a must have feature or they were leaving. It doesn’t matter what the reason, 33% of your next sprint has changed. This ripples down through the rest of the backlog.

For this team, they have a volatility factor of 33%.

Now, what is the point you might ask? Well, it helps you understand a few things.

1. How accurate are your roadmaps going to be when you show them to the rest of the company?
2. How much should you plan for future release?

This last point is very important. In the above example, I should have only planned sprint 2 for 67% capacity and sprint 3 at 33% capacity. This is until the volatility factor starts increasing. It will save time, and give a more accurate results. That way I am not planning for something that is probably not going to happen.

Is volatility a good thing or a bad thing? I don’t really know. I would like to say it is bad, and the lower the volatility the better. But, in an agile world, this volatility may be the difference between building something great, or waiting until someone else has already built it to get started. All I know is it needs to be understood.

Unfortunately, I just thought of doing this today and figured I would blog about it. I haven’t done it yet. I do think it will help expose teams that are hard to plan for and help bring those problems up with the rest of the organization if nothing else, and maybe save me a little time.

Anyone think it is a good metric to track? Or am I wasting my time?

Last week, Rex came to me asking if the Webmail Apps team could have their sprint planning at a park here in Blacksburg. I thought it was a great idea, and yesterday we had an awesome morning of planning, followed by some grilling.

Lately, the project management team has been pushing a lot more of these type outings. In my opinion, it stems from the fact that developers hate meetings. Even though sprint planning meetings are needed and important, teams hate sitting in some conference room for hours. Especially when they did it last month, and the month before.

Today’s scrum tip is one I have stolen from our project management team. Get your team out of a conference room for planning. Switch it up. Your teams will enjoy the change of scenery.