Brian Hartsock’s Blog

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.

1. I bought a house!
2. I am moving into that house
3. Product backlogs

Our company blog, Rackspace Email & App’s blog, just had a post from Rex. It’s all about Scrum here at Rackspace (yes, I no longer respond to Mailtrust since our recent name change).

I encourage you all to follow the Rackspace Email and Apps blog (yes, shameless self promotion) for any tips from our project management team. Rex is the PM for all my software development teams and all my scrum posts are either stolen or inspired by interactions with him and those teams.

Being a product owner is hard. Making sure you achieve the proper balance of tasks across different stake holders in a product isn’t easy. Support and operations need certain enhancements that make servicing the customer easier, while the business needs to advance with new features as well, and the designer wants to make the user twice as happy by tweaking a few things. All good things, that require good prioritization in order to make a successful product.

So be wary of how you prioritize.

A while back, I started noticing something odd about my priorities. The following scenario kept happening:

• Monday - Someone asks for feature A
• Tuesday - Someone asks for feature B
• Wednesday - Someone asks for feature C
• Thursday - Someone asks for feature D

On Friday, during sprint planning, the priorities end up being D, C, B, then A. I was allowing the most recent, and loudest, voice win and not some sort of metrics. I didn’t have enough info to effectively weigh A vs D. I was flying blind and trusting the loudest voice, which isn’t a good thing.

When requests to the product backlog come in, don’t take them blindly. Challenge the requester. Ask if they really need this. Push back. Dig into why a request is needed, so weighing it against other requests is possible. If you aren’t challenging your stake holders, you will end up with a backlog miles long that is very hard to prioritize. If nothing else, the process will help you better understand the request.

This is about where I am today. My next step is to follow Dharmesh’s advice, and start weighing different attributes about each request. This way changing priorities don’t completely change the product backlog, they just change which attributes we value the most.

Let me know any tips you might have on prioritization.

One of the nice things about Scrum is the lack of rules. There aren’t a lot. And the rules that are given, should be changed over time. Scrum, like development, is an iterative process of continual improvement. A very important part of the Scrum process is sprint length.

If you’re thinking I am going to tell you an ideal sprint length, you are wrong. My Scrum tip of the day is just to make sure you’re adjusting sprint length based on many different factors.

There are a few very important things to look at when deciding on sprint length.

• How volatile are priorities? If they change very often, long sprints are going to get interrupted, whether you like it or not.
• How big is the team? A big team means sprint planning can be very painful. Do you want to have shorter, but more often plannings? Or longer, but less frequent plannings?
• More meetings. The more often sprint plannings are, the more often demos and retrospectives are. This can quickly drain product owners and stake holders that are part of multiple projects.
• And the biggie, motivation. Long sprints can have lulls in motivations. Short sprints seem to keep motivation a little higher, and the team focuses more. The power of short iterations to give a team motivation is one of the greatest strengths of Scrum in my opinion. Don’t forget about it

I know what you’re thinking, “great, but how does this help me?”. All I can tell you is what I have experienced.

Smaller teams seem to gravitate towards short sprints, around two to three weeks. Planning’s are pretty simple and quick. The short sprint allows for the team to turnaround things really quickly, and I personally like it a lot as product owner.

Larger teams are the opposite. Even though larger teams usually have more volatile priorities, they can’t stand planning meetings so they space them out more. Most of the larger teams do a 3-4 week sprint.

My tip to you, play around with everything from 2 to 4 weeks. Anything shorter, and you have too many meetings. Anything longer, and priorities can shift too much and motivation starts to slide.