Don't Crap in the Product Backlog

I've got news for you, if your product backlog has so many items (stories, features, bugs, back log items, call them whatever you like) that you feel the need to create a web of dependencies that you then need to visualize in a chart or use some other huge time sink, then you're doing it wrong. There's too much crap in your backlog and you're drowning in it.

This is an astoundingly common problem and one I deal with on a daily basis as I interact with various Scrum teams. Here's what the problem looks like:

1. Change wording in system options from "Foo" to "Bar" in random context menu.
2. Move dropdown menu in system options from "Bar" tab to "Foo" tab.
3. Simplify security settings for "Foo" in system options menu.
4. Other random change to system options that is too small to ever make it into a real sprint

Multiply this by every feature in the product and you end up with a backlog spanning 100s if not 1000s of things to track. The problem here is that any tools you use to manage this behemoth product backlog is really just masking the problem bigger; you're getting lost in the details and missing the bigger picture.

Don't look for ways to manage everything, look for ways to make everything simpler and the problem will solve itself.

So what should those 4 backlog items look like?

1. Optimize the system options menu

That's it. Each of those 4 original backlog items are bullet points inside of the bigger one and I've effectively shrunk the amount of crap I have to manage by 75%. Do this with your entire backlog and you'll get something you can actually refer to in conversation with the team.

Product Owner: I'm thinking we should probably get around to the menu item in the backlog

Team: The whole thing or just parts? I took a peek at it last week during Sprint planning and it was getting pretty big, that's one of the reasons we didn't do it then. Has it changed much since then?

Product Owner: I've changed it a little since then, but I don't think we need the whole thing done by next sprint. I'll pick out the bits I like and send it to the top of the priorities, but we've been putting those changes off for too long already.

As opposed to:

Product Owner: There's a bunch of menu changes in the backlog I'd like to try to get some of them done in the next sprint.

Team: There's work for the menu in the backlog? We never got a chance to look at the whole thing during sprint planning. What kind of changes are we talking about? I haven't had time to even look at any of the menu changes yet.

In the first example, the Product Owner can refer to something in the backlog and the team knows exactly what he's talking about. In the second example, the conversation needs to refer back to an artifact, list or tool for even general conversations.

You'll notice by the way, in the first conversation, the Product Owner wasn't afraid to pick out the bits in the backlog item that should be implemented, in effect, he's splitting the product backlog item, but he's only doing it when he needs to. The same thing will happen with the estimation; the team will estimate the new backlog item that's high enough in the priority for them to do. The other will probably sink lower into the backlog and doesn't need to be estimated until it makes it to the top again. If the item needs to be split again to fit it into the sprint then it's usually handy to have the Product Owner around so he can help figure out which half needs to make it into the sprint.

So, what about when feedback comes in? After all, the backlog is filled directly (if possible) by the stakeholders and those ideas are likely to be fairly small compared to our new larger items. The product owner should look at each and every backlog item that comes in and if the item doesn't seems similar enough to other backlog items, it should be assimilated by another item.

More objects, more moving pieces means more administrative overhead for the Scrum Master and the Product Owner (they have enough going on as it is). Like most things in Scrum and for that matter like most things in life, make things as simple as possible (but not simpler) and only add complexity as the need arises.

Related Posts:
6 Things a Product Needs to Know
Should Your Scrum Team Stop Using Story Points?
5 Big Issues when Scaling Scrum

Implementing Scrum: Top Down and Bottom Up Approach Part 2

We've already discussed implementing Scrum from a top down approach and came to an interesting conclusion. Establishing trust between the Scrum Master and the Team is key in a top down implementation.

So what about implementing Scrum from the bottom up? This is sometimes referred to as the "grass roots" movement for Scrum where a development team decides to abandon some of the more traditional aspects of how they make software and move towards a more Agile environment.

This type of Scrum implementation can cause an entirely different class of ulcers for your average Scrum Master since the business employing everyone is not likely to be enthused about a large change in the way they interact with IT that they did not initiate.

In order to find a solution here we first need to understand the problem. Unfortunately, things aren't quite as clear cut as they would be with a top down implementation of Scrum. The reason here is that different businesses have different needs of their development teams and it might be difficult to communicate how Scrum fits into to all of that. So your first job is to find out what the business needs from the team, while there's no definitive list for this here's a few that I've seen as common:

• The business needs the product to be useful
• The business needs ALL of it's requirements met
• The business needs software quickly
• The business needs predictability

Understanding the businesses needs (which may or may not include "Being Agile" so much as "Making Software" or "Having Software") is the first step here. The second part is to actually give them what they want.

The Business needs the product to be useful

It's fair to say that somebody would eventually like to use this software. Since we're building software in iterations and we have either somebody from the business or somebody focused on the business's needs setting our priorities the end-product will be in a useful state much faster.

The business needs ALL of it's needs met

This also needs to be taken into account with two important caveats:

• The needs of the business at the start of a project rarely match up exactly with the needs of the business at the end of the project.
• It's impossible to gauge the usefulness of a tool until you have it in your hands.

Both of these problems are solved with one simple axiom: Ship software faster. Will the first release to production include all of the requirements laid out up front? No, but this release hits all of the primary concerns, you can begin using it almost immediately and we're working on the remainder of the requirements as we speak. This brings us to the next concern for the business.

The business needs software quickly

Very rarely are you going to get a project that needs to be shipped a year from now, usually it's a project that needs to be shipped today but will be shipped a year from now because that's how long it will take to create. So let's shorten that first ship date and satisfy the most important of the businesses needs now (or as soon as possible) and use their feedback to make the product better with the time we have remaining.

The business needs predictability

This last part can be a bit more difficult since we live in an unpredictable world but predictability can mean a lot of things. Instead of predicting "It will take us 13 months to finish this product", start with something like "I can have you something that works within 3 months and we can figure out where to go from there". While it may not be possible to predict with certainty everything that you can get done in 3 months you can probably guess that the team can get something that works done in that period of time.

I can go on about any of these topics way more but this is a blog post and not a thesis so I'll leave it brief for now. Here's the important part, you have to figure out what the business needs, tell them how you're going to deliver on those needs and then you have to deliver. That's important so it'll get it's own paragraph.

You have to figure out what the business needs, tell them how you're going to deliver on those needs and then you have to deliver.

The reasoning behind this is simple, management, your customers and/or the business that supports you needs to embrace Scrum every bit almost as much as the team. This is especially true since you'll be bugging them much more often for collaboration than you did previously. If you do it right though, you'll be able to show them results and results are difficult to argue with.

By delivering results you'll have gone a long way towards earning trust and that trust allows you to ask for things that you'll need down the road such as a path into the backlog for every stakeholder, a strong product owner (which you may not actually get to start with) and a little bit of understanding as to how development actually works.

Like most relationships built on trust, you'll need to extend yourself (along with the team) first. That may mean starting your first sprint without a full-time product owner or without a lot of room for collaboration on the backlog items.

Luckily though, you have the team to back you up here and they're primarily what you need to ship software. The team's performance is what's going to earn that trust from the business so get out of their way, let them ship software, keep the business off their backs and deliver software. When you're asked why your performing so much better, tell the world "Were doing Scrum now and it's going really well, we could do better though. I need some help from the business side for that."

Related Posts:
Implementing Scrum: The Top Down and Bottom Up Approach Part 1
What Does a Scrum Master Do All Day?
Your First Scrum is Going to SUCK!

Implementing Scrum: Top Down and Bottom Up Approach

This is going to be the first of two articles discussing the top down approach (Executive decides that the team should use Scrum) and the bottom up approach (the Team decides that they should use Scrum). Both introduce interesting problems, so they're both worth discussing. Let's talk about the top down approach first.

Implementing Scrum from the top down can be a bit daunting, especially if the team you'll be working with is skeptical of Scrum. In fact, you may be walking into a room of developers who already see you as a liability, rather than an asset, before you even introduce yourself.

Make no mistake, without the trust of the team, you are doomed for failure. Without establishing trust, you can't really expect the team to really interact and collaborate with a non-developer (the product owner) or expect them to estimate their work if they've never done that before. These may be new things to the team and they'll need to trust that you're not wasting their time.

So how do we get it? You'll have to understand the team, help them achieve their goals and hopefully earn a little bit of trust in the process.

To understand the problem, you'll need to understand this first; it's very rare to find a developer who'll tell you that they'd rather spend more time in meetings and less time writing code. In fact, if you're a developer working in a traditional command and control, rigidly controlled PMO type environment then in my experience you probably want nothing more than to be left alone so that you can simply write good code.

So give that to your team. It's as simple as that. As plainly as you can, implement Scrum by telling the team that you're going to start working in iterations, they can choose the iteration length with some basic guidance (you don't get a 2 year iteration), they can estimate in whatever way they want, they're not going to be individually managed and they can use whatever engineering techniques they want. Bonus points if you can communicate this without booking a conference room.

The catch? They have to write and test their code and have it all potentially shippable at the end of the iteration. When they're done they'll chat about how it all went down and then do it again.

In essence, you have to tell them that you're going to get out of their way and do the job that they signed up for.

Here's the hard part. You actually have to do that.

We've already established that your first sprint is going to suck, so don't try to implement every Agile solution you know right up front. In fact, implement as little of Scrum and Agile as you can feel comfortable with. Believe it or not, software developers know how to develop software, so you'll still get something done that you can measure and improve on for the next sprint.

This means that a lot of the techniques and tools you learned at your Certified Scrum Master training are about to take a back seat to the team's solutions. That's okay, these guys are smart and they may come to a lot of the same conclusions on their own, even if they don't, they may ask you for advice or come up with a better solution on their own. It's not your job or role to tell the team how to do their job.

• If the team doesn't want to estimate with points, don't make them.
• If the team doesn't want to partner program, that's fine.
• If the team doesn't like sub-tasks, that's okay too.

As a Scrum Master interacting with the team, you care about two things, that the team has everything at their disposal to do the job right and that the team remains uninterrupted during the sprint. Everything else is details and in the grand scheme of things, those details are not important.

You'll find that this builds the kind of currency (trust) that you'll need down the road as you guide them further down the Agile path or begin to facilitate collaboration or any number of other things a good Scrum Master should do.

Trust is really the secret sauce that you'll need here, the team needs to trust you to guide them and you need to trust the team to make great software. Once you establish that trust you can take the team anywhere they need to go.

As a Scrum Master, how have you built trust with your developers?

Related Posts:
What does a Scrum Master do all day?
Your First Scrum is Going to SUCK!

Should Your Dev Team Stop Using Story Points?

Let me preface this post by saying this: I get Story Points, I understand how they work, how they should be used and the problem that they are purported to solve.

Here's the thing, I'm a minimalist at heart. My first (and typically second and third inclination) whenever I learn something new is to strip it down to it's minimal working moving parts (there's an acronym in there somewhere). With story points it seems that the industry has reached a solution without fully understanding the problem.

Q: So what's the problem?

A: Detailed estimates are always wrong. Will always be wrong and can never be accurate except by pure luck.

Q: Why are detailed estimates always wrong?

A: Because the real world is a complicated place and it's impossible to see clearly into the future.

Story points answer this by doing something important, they abstract the estimate and allow us to estimate with a larger unit of measurement therefore granting us the freedom to estimate with a lower level of precision.

But the abstraction introduces a new problem. Allow me to illustrate with a couple questions.

• Why do you estimate?
• What is the problem with misestimating your work?
• What is the most concrete and important constraint of a sprint?

Since blogging is a bit of a one way conversation until it's published let me fill in some of your answers.

• You estimate so that the team has a realistic amount of work in a sprint.
• Misestimation of a sprint is a problem because the team will not have enough time to finish the sprint backlog if they overcommit due to poor estimates.
• The most concrete and important constraint of a sprint is time (unless you have a tool that can stop or slow time, in which case I want in on the beta).

So when we look at it objectively, we're actually fooling ourselves by pretending we're not estimating with real time units.

Now in some cases this is a good thing, it's a bit like Mom mashing some cauliflower into the mashed potatoes so we'll eat some real vegetables but I don't see it as something to default to or even a permanent solution to the estimates problem.

So what's the real solution? Combine the best of both worlds.

Estimating in logical time boxes.

Instead of estimating in units of measurements, we estimate in predetermined timeboxes.

A slight tweak should only take a couple of minutes? That falls into the 1 hour timebox. A bugfix should take me the better part of a day? That'll fall into the 1 day time box. What time boxes should your team use? Probably not fibonacci numbers since they'll imply some level of precision which shouldn't be there and tshirt sizes are missing the point of estimating in time as well. The answer is that you should decide with your team but, here are some good ones to start with:

• 1 hour
• 4 hours
• 1 day
• 2 days
• 3 days
• 5 days
• 2 weeks

At some threshold with these you'll want to decide to split the backlog item into more manageable chunks and you'll want to estimate with the assumption of one person working on an item from beginning to end. In practice there may be multiple hands on that item at any given time but we want to capture total time expended not calendar dates in progress.

So what've we learned? A lot actually.

1. Detailed estimates are dumb and we shouldn't do them.
2. Story Points mask the point of estimating and can potentially sow the seeds of confusion.
3. Estimating with time units isn't that different than estimating with story points since you'll still estimate with distinct values rather than detailed units.

Let me know what you think in the comments.