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.

Estimating is hard. Developers, at least in my experience, are notorious for making their lives harder and underestimating tasks. No matter how often you tell them to be realistic, it doesn’t happen. There are a few things that can be done to mitigate this.

• Be realistic about the hours actually focused on development. Many team members, especially team leads, spend a lot of time doing other tasks outside of a sprint. Make sure this is accounted for somehow.
• Break things down, then break things down further. However you estimate, if part of the estimation exercise isn’t breaking things down to very manageable chunks, estimation is impossible.
• Quiet planning meetings are bad. In a previous post, I said the team should just have a conversation regarding what the details of the story really are during planning. If this conversation isn’t being had, I bet someone on the team doesn’t understand it enough to estimate. Have this conversation

Lastly, don’t strive for perfection. Estimation is a dirty game that you can get good at, but mastering just isn’t worth. What matters is that things are getting done with quality in a predictable fashion. I have seen a few teams lose focus of what’s important trying to achieve better estimation. Believe me, I would much rather have a team spend an extra day making something remarkable and being a little off in their estimations.