Your Scrum team's velocity and how to misuse it.

Your team has a velocity, whether you choose to measure it or not is irrelevant. On an average day, your team decreases the amount of work they have left in a release or a sprint. The average amount they decrease that work remaining per day is the velocity of that team.

This shouldn't be new information to most Scrum teams (if it is then let me know) but something I run into on a frequent basis is the misuse of velocity. Let's run through a couple examples:

Individual Velocity: This is by far the most common question I get about velocities and the simple answer is that individual velocity is not a meaningful measurement.

Let's say that we have a developer named Bob. Bob's a fantastic developer and can think his way through very complex problems, build amazing algorithms and writes beautiful easy to read code, but he's never spent a great amount of time with C# which the current project is built in. Luckily Bob's part of a great team, they interact in a really meaningful way and as a result Bob still writes great code and he's getting up to speed in C# as his team can help him fill in the gaps when he's struggling with the language. We'll say that based off of the backlog items he scratching off the list every week that he's got an individual velocity of 7.5 hours per day.

Now based off of this information, we could expect to see a 7.5 hrs/day improvement for the velocity of any team we add Bob to, right? Not so much, let's put Bob on a different team that works very fast but doesn't communicate all that well (a team of cowboys if you will). Suddenly Bob's velocity drops significantly because his team can't help him fill in language specific gaps in his knowledge. What's worse is that Bob's old team saw a dip in the their velocity that's more than Bob's 7.5 hrs/day since they no longer have Bob's amazing mind to help them through some of their more complex problems. This is to say nothing of the velocity of our cowboy team now that they have to "carry" Bob.

What we're seeing is that Bob's velocity is more than just the completed items with his name attached, it's also the way that he contributes to his team and the way that his team contributes to him. In all reality, there's no practical and meaningful way to separate Bob's velocity from the team itself. Even worse, it invites us to act on bad information since measuring individual velocity gives us the illusion of empirical data.

Point Velocity is absolute: Story Points and I don't see eye to eye but we understand one another and I think they can be used effectively in a lot of places (I just don't feel like they're a requirement for doing good Scrum). One thing that always makes me nervous though is when I see multiple teams working on a single product backlog and sharing point values.

Here's the thing, a story point is not an absolute value. When used correctly, a story point doesn't equate to time and it's value is unique to the team that created it. This means that Team A may look at a story and determine that it's value is 5 story points and Team B may look at that story and label it as 8 story points. This might be because Team A is more familiar with the type of work for that story or maybe they just view points on a different scale, it doesn't make their estimate wrong and it also doesn't make the other team's estimate wrong; just the opposite, it makes that team's estimate more accurate since they created it, it makes the estimate relative to the team doing the work.

None of this is really a problem for the estimate's main purpose which is helping the team establish the correct number of stories to forecast for the next sprint based off of their previous velocity. The problem is when I start combining the velocity of Team A with the velocity of Team B for an overall sprint velocity, since the two team's estimates don't always mean the same thing I'm essentially adding apples to oranges, assuming they're the same price and heading to the checkout counter. Compounding this problem is that this behavior invites stakeholders to compare velocities and make value judgements where they may not be warranted (Team B is finishing twice as many story points as Team A which means Team A must be slacking off), this can lead to estimate inflation (which make the estimate essentially worthless) or lower quality work in order to deliver more points than the other team.

Now an absolute estimation method will fare better under this scenario but it's got it's own problems. It's up to you to decide where to compromise with your estimates but if you decide to use points just keep in mind that your team velocities, while useful by themselves, shouldn't be combined.

I could go on with other velocity pitfalls but these are the most common that I see and this post is already getting a little long in the tooth. If you'll direct your eyes to the top of the page you'll notice that I'm putting on another Scrum webinar this Thursday at 11am PST. I'd be tickled pink to see you there, admission is $49 and you can find all the details by visiting the link above.

(Update: The Scrum Webinar went very well and I appreciate the great group of people that attended! I will inform everyone when we schedule the next one.)

Why self-organized teams are so important

It's a situation that I run into with new Scrum teams all the time.

Their work is complicated you see, there's all of these dependencies for every backlog item to be implemented and each task needs somebody with a special skill and we have to schedule how each person with the correct skill will finish each task in a certain order so I need some way of planning all of this and managing it within each sprint. Before you know it, there's gantt charts up on the walls and people are calling other people "resources". This is the reason why I keep my migraine medication handy at all times.

The problem here is that the very first assertion made here is absolutely true. Implementing a new feature in a complex system is complicated and there are certainly more factors involved than any one person can manage effectively.

Luckily the solution is actually rather easy. Make the management of this complexity as close to the work as possible, this actually means removing the project manager and allowing the team to decide for themselves how the work should be done.

Now almost as soon as you start doing this you'll begin to find impediments to the team getting their work done. The most major of these is that many new features and bugs need more than just a single person to complete them, at the very least you'll need somebody to code it and somebody else to test it but you may also need someone to modify a database or code a UI or design graphics or write up a help file.

To be clear, I actually don't agree with the approach of classifying developers by specific competencies. I feel like a developer should be able to code something into an application from beginning to end regardless of which part of the app needs to be modified. This makes development much easier, a complex feature may be developed by a single person and the only reason another person may be needed is for testing or pair programming.

I do realize that this is not always possible in every organization so I invite you to the middle ground: the self-organized cross functional team.

Cross functional means that the team as a whole includes everyone needed to implement any backlog item from beginning to end, including testing. This means that the team will consist of UI designers, Backend Developers, Database Administrators if needed and definitely testers.

Self-organized means that the team decides as a group how to implement those backlog items. This means that if a feature was started by Joe the UI developer but he needs something changed by Jim the DBA then all he needs to do is tell Jim to make that change when he gets a chance, no complex scheduling needed just individuals and their interactions getting things done.

Now in order for this to work you need a lot of collaboration between team members. Please note that this does not mean that the developers spend more time shooting emails back and forth, it means that they spend more time actually interacting. Preferably with real face to face communication.

 In many cases a lot of this collaborative talk will be done during the daily standup as developers chat about what they're planning for the day and their impediments, as a Scrum Master you'll want to allow enough of this during the standup for them to plan out who they'll team up with to complete their work but not so much that it makes the standup longer than it should be. Get used to the phrase "You two should be able to work out the details after the standup, let's keep moving". Also, try to keep the team from planning their individual plans more than 1 or 2 days ahead of time, any more than that and plans become hazy.

You may also consider a couple other options for increasing collaboration (and therefore the team's ability to self-organize) by removing the cubicles and allowing the team to work in a single room with no walls separating them. This way if a developer needs somebody else for a particular change or task they can simply ask them without having to visit their individual office or cube. When doing this (or when deciding on teams in general) keep in mind your individual team sizes, a team larger than say 9 people will begin to find it difficult to communicate as a group effectively and you'll actually begin to hinder collaboration rather than help it. The ideal team size is 7 plus or minus 2 and the same should hold true for your team rooms.

Finally, it never hurts to encourage the team members to become cross functional as a whole. Introduce the team to pair programming. It's up to them to adopt it or not or to modify it into something that fits their own team culture but the more they can see of code outside of their own specialty then the easier it will be for their team to take on complex work.

Scrum: The Test Heavy Backend of a Sprint

You might hear me mention at some point that as a Scrum Master, I don't really care about the technical details that make a product backlog item done. I only really care about some form of measurable daily progress and the fact that these backlog items actually get done.

So, does that mean that the method for building said software is unimportant? If all you care about is Scrum and that which Scrum defines for you, then yes, it's unimportant. If you care about actually making working software (which is the real goal), then it's not just important, it's vital.

Ask yourself this, why do you always hear about test driven development, pair programming, code coverage and other software engineering techniques when talking about Scrum if Scrum, as a framework, doesn't define these things at all? Because, they solve problems that Scrum teams will likely run into. When a team builds software with traditional project management, there are certain problems that tend to hide themselves (or at least make themselves easy to ignore). Scrum brings these things right up to the front and forces these problems to be solved.  Most of the time these problems are technical in nature and should therefore be resolved by the Scrum Team (not the Scrum Master).

This is one of the reasons why eXtreme Programming (or XP) is often paired with Scrum. Many of the techniques found in eXtreme Programming tend to solve problems that a Scrum Team is likely to uncover.

Let's talk about only one of these problems/solutions for now.

When a team first starts developing in short iterations (which Scrum has you do), they will probably fall into a very common trap. They will finish writing the code during the first part of the sprint with the assumption that the latter half will be spent testing. Here's the thing, this could actually work if you didn't find any bugs in testing, but you will. So in reality, you'll have the latter half of the sprint to find bugs, fix them, retest them, and fix any new bugs that the fixes introduced. It's a confounding problem because individual bugs can't be anticipated and therefore make estimation a nightmare. What we need is some way to normalize the time we spend on quality in the software, so we spend less time chasing bugs.

Let's try this again; let's say I'm a developer in the middle of a sprint and I pull a backlog item from the sprint backlog, but instead of immediately writing code, I take a second to chat with a tester about how we'd like to test this when the item is done. While we don't know what the code will look like yet we do know what the finished code should do so we create a test case together and I go about writing code to make that test case pass. Once I'm done writing my code, I know that it'll pass the test we wrote but I pass it off to the tester just to get another set of eyes on. He confirms what I already know, which is that the backlog item is Done and we're that much closer to finishing up the sprint.

In both cases, we still tested, but by writing the test up front, we can gain some insight right away on how the code should be constructed.

Notice that I'm not telling you what tests to run, only that you should define the tests before development. The tests themselves may be anything from writing an actual unit test before writing the actual code or it may be as simple as a conversation of "I'm going to do X, Y and Z when I test it" before you sit down to make X, Y and Z possible in the product. The more detailed the test plan is up front, the less likely that you'll run into last minute surprises and that makes everyone's life easier.

Related Posts:
Your First Scrum is Going to Suck
What does a Scrum Master Do all Day?
What is the Deal with Story Points when Estimating?

No New Post Today: Go watch the OnTime v11 Launch Live

Hi Everyone, I normally try to have an article up and written at least every Tuesday but I decided that just this once you might be better served by watching the OnTime v11 (The Scrum tool that we make at Axosoft) launch on Axosoft.com. Our CEO Hamid will be demonstrating the tool and talking about everything that went into making it our biggest and most ambitious project ever. Starts at 11:30am Pacific Time tomorrow, see you there!

Organizations Against Scrum: Iterations First

"Scrum doesn't work here"

"We tried Scrum and it introduced a bunch of problems"

"We failed a big project because of Scrum and management doesn't want to try it again"

I hear these things every now and then and they stick in my brain. My first thought when somebody says something like this is that Scrum didn't cause any problems, so much as it exposed problems that were probably already there. As you can guess, this can cause some mild discomfort in any development team.

For instance, you say, "We never had enough time for testing at the end of the sprint"

And I hear, "We trade quality for speed in development and we immediately see the effects of that decision within a sprint". Essentially, you're seeing that you actually do not gain any time by hurrying development in the beginning, you just push it off until later and that's uncomfortable for your PMO to hear (although your developers have probably been telling you this for years).

That isn't a problem with Scrum, but it is a bad habit your organization has developed over the years and Scrum will pull that out into the open for you to fix. This is not a failure of Scrum, in fact some would argue that it's the whole point of doing Scrum to begin with. If you fail to fix your testing problem, then it's likely that you'll feel the effects when testing comes around anyways. This would be true in a waterfall project as well, the only difference is that the time between the issue and the consequence is longer in a waterfall environment.

I could go on with at least a dozen or so more examples, but at least with this post, I'm not going to go into the myriad of different ways that you can force a development project to fail using Scrum (that's a very long post for a future date). I'd like to talk about how to reintroduce Scrum to a wary audience.

Don't call it Scrum.

Yup, it's that simple. Start with something basic like building in iterations. You can even grab work from the schedule based on due dates to decide on your sprint backlog if you can't get a product owner to provide priorities. Start building in iterations and inspect and adapt after every single one of them.

The iteration (or sprint) is the cornerstone of Scrum and also the hardest part to do because it exposes problems and this can cause some discomfort. You'll discover things like how poorly your team estimates or how bugs really affect the productivity of the team (this often hides in the latter part of a waterfall project and is quickly forgotten by the time the next project rolls around).

Solve these problems over your first iterations, earn some credibility and then start implementing more Scrum and Agile concepts. Remember that when attempting to convert a skeptic, the best way to start is to show them something concrete rather than asking them to take a leap of faith.

*Disclaimer* I'm not suggesting that you introduce Scrum to your team like this, if you're new to Scrum then try to do things close to the correct way as possible. The iterations first method should really only be used if your organization is specifically entrenched against Scrum to begin with and you need to establish Agile. *Disclaimer*

Related Posts:
Implementing Scrum - The Top Down Approach
Implementing Scrum - The Bottom Up Approach
Your First Scrum is going to SUCK!

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.

6 Things Product Owners Need to Know

So I've identified what appears to be an issue for the Scrum Community. It's consistent in that the area of improvement always seems to be the same but the way that the problem manifests can be different.

photo credit

I'm looking at you Product Owners, time to step up your game, understand your role and help take the team to the next level. Here's 6 things that you should know about owning the product:

1) Trust is key:

Particularly early in development for a new product there will be a lot of Product Backlog items which may or may not be understandable without development experience. At this early stage you'll be relying on your Scrum Master and in particular the development team to explain the need for these things so that you can properly prioritize them. My suggestion is to build a good relationship with the Scrum Master and at least one (preferably all) of the developers who can act as a guide for some of the more esoteric work that may need to be done in the sprint.

Likewise, that trust will be needed both ways. If the team knows you well enough to suggest some changes to the product that you may not have thought of or understand (refactoring comes to mind) then take some time to listen. More often than not these types of technical changes will ultimately make development much easier in the long run rather allowing for faster feature development, more reliable code and better performance in the long run. You'll find that this type of really valuable feedback will simply disappear if you don't take the time to earn your team's trust.

2) Your job is to serve the team:

The ultimate goal is to ship great software, that's why you're there, that's why the team is there and in a roundabout way that's why the Scrum Master is there. That being said, which role in a Scrum organization is most likely to get blocked, thus preventing the shipping of said software? If you answered the Scrum Team then you are correct. While it's not something that you can prevent altogether it's definitely not a problem that you should contribute to.

Let's imagine a scenario where the development team is working on various aspects of your product. One by one, (or even all at once) they need some feedback from the product owner so they call you and it takes you day (8 productive hours) to get back to them. One day turn around time isn't so bad right?

By applying the power of math, assuming a 14 day sprint and the loss of one day due to the product owner waiting to get back to the team, that's slightly more than 7% of the sprint lost to the product owner turnaround time which is likely a wide enough margin to cause sprint failure. Part of the whole point of having a product owner is to provide a single dedicated source of feedback for the team since the actual customers are usually off doing other things (which usually don't include software development).

My thought on the matter is that the Product Owner (and the Scrum Master) should adopt a helpdesk mentality when the Scrum Team requests some feedback. That request should be turned around in a matter of hours, minutes preferably. If at all possible, try to position yourself in the office WITH the Scrum Team and make them feel comfortable walking into your office (or cube, or whatever) to ask questions and get feedback when they need it.

3) It's your job to understand our customers:

Q: What do developers know really really well?

A: How to make software.

Q: What is unlikely for a developer to know really well?

A: How to work a warehouse, file insurance paperwork or anything else that your stakeholders will use the final product for.

Ideally you actually are one of the customers and bring a ton of domain knowledge to the party but if you're not (or even if you are) you need to spend whatever time you can understanding the end users who's needs may encompass more than what you're familiar with.

This means contacting customers who provide feedback personally, spending time with customers who actually use the product and/or a legacy solution to find out what they like/don't like. Being an active part of the online community (if there is one) for the business area and just generally getting into the head of the folks who will ultimately use your product.

This also means putting your ego aside in many cases to allow some backlog items you may really like to take a backseat to functionality that may be important to the customer base as a whole.

4) The Team occasionally fails

Each sprint adds value to the final product but that doesn't mean that the Scrum team will always deliver exactly what they committed to. Some sprints may see them over-deliver while other sprints that fail to implement everything. Neither Scenario is good or bad, it simply means that software development (at the team level) is unpredictable at best.

Think of it this way, if the team maintains a planned velocity of 100 hours per sprint but delivers the first sprint with an actual velocity of 90 and the second sprint with 110, what's the average?

The point here is that sprint success or failure isn't necessarily important to the Product Owner so much as the team delivering value to the product so don't sweat the details here and use some of the trust we talked about earlier. The team occasionally fails because they're trying new techniques, setting ambitious goals for themselves and is generally looking to improve every sprint, this results in the occasional failure but will generally trend towards a faster more efficient team over the length of the entire release.

5) You are not a Project Manager:

This part is actually a bit tricky but ultimately, it's your neck on the line as the Product Owner if the Product ends up sucking. But that doesn't mean that you set the schedule for the team, worry about how the allocates the work or god forbid, plan the sprint backlog. It's your job to set the teams priorities at the backlog item level and to provide valuable feedback for the team. If you attempt to control any aspects of development past these levels then frustration and team unhappiness will result.

Here's why, planning the day to day details of development with the individual tasks or even the backlog items reveals a wealth of complexity such as the expertise of the individual developers, dependencies at the task level, individual schedules, sick days, vacation time and various other aspects that have given project managers headaches for decades using the waterfall method. These things don't magically go away using Scrum but we absorb them at the team level which makes life for everyone much easier.

You see the team understands the technical intricacies involved with their work because their the ones doing it, they (should) know each others strengths and weaknesses and even each others schedules better than any Project Manager, Scrum Master or even Product Owner ever could which makes the team the most logical place to hammer out those details. This is the primary reason why the team decides on the amount of work to pull into the sprint backlog rather than any other role.

6) The Sprint Review is not a dog and pony show:

The sprint review is one of the few aspects about Scrum that should be done behind closed doors. The purpose here isn't to celebrate new features, berate the team for missing functionality or anything of the kind. As a product owner, it's your job to see what the product looks like at the current iteration, provide critical feedback, make some tweaks to the backlog and/or stamp the product ready for release. When the Sprint Review becomes a public meeting that instant feedback becomes much harder to give, details get lost, that part of the interface that crashes isn't clicked on. In essence the Sprint Review (while great for morale) becomes much less useful as a feedback mechanism.

Final Thoughts:

I could go on for hours about any one of these six points and you may see more detailed posts about them in the future. The truth is that a strong Product Owner is often the secret sauce that separates a great software development team that amazes customers from a mediocre one that simply pushes out a release every now and then.

Dependencies in the Product Backlog

A backlog item should be big enough that it's not dependent on any other backlog item to be completed.

photo source

Hopefully, you already know that, and in a perfect world, that's how we'd all live, but the fact of the matter that every new feature is dependent in at least one small way. You can't add in a nifty planning board into OnTime if it didn't already do work item tracking right?

So if dependencies are part of our day to day reality then how do we deal with them? I'll answer that by rephrasing the first bit of wisdom in this post.

A product backlog item should be big enough that it's not dependent on any other incomplete backlog item to be completed.

"But Sean" you'll say "Story #231 is too big to accomplish in a single sprint and it's the next story in the backlog!"

"Then break it down into smaller pieces" I'll reply

"Didn't you just contradict yourself?"

"A bit but here's what I mean straw man"

Once you decide to commit to a very large backlog item you'll probably work on it for the next couple of sprints but you need working, tested software at the end of the iteration, what's more you'll probably want to break it down to make it easier for the team accomplish. Here's my thoughts on the matter.

We decide on Story #231 which is Big, we think we'll need roughly about 3 sprints to get it done so we break it up into smaller logical pieces (ideally 3 pieces, but common sense is the best rule here), all three pieces can be accomplished with a single sprint each and they all get thrown to the top of the priority list since that's where they sat before we broke them up. If they're dependent on each other, then the first one will be prioritized highest, the second is next and so on and so on.

Now we've got one big story in the first sprint, which isn't very helpful at all when we begin working, so we'll break it up into smaller pieces again for the development team. Generally speaking, you should be breaking things up at this point to be small enough for a team member (or paired team) to tackle from beginning to end by themselves within the sprint. From there, the individual developers should start thinking about breaking their own work items down into logical steps (or tasks) which should be small enough for us to see daily progress on the steps completed.

You'll repeat this again until the Big backlog item is completed, then dip back into the backlog for the next item.

The tendency with new Scrum Masters and Product Owners (and even experienced ones) is to look at the backlog and break everything down as soon as we get it. The problem is that now we need to maintain backwards traceability to the parent story (software can help with this but it'd be better to not need it), we have to educate customers on the breakdown of their feature request or bug (they think of them as Features and Bugs no matter how many times you use the word "Story" or "Backlog Item") and we end up making more work for ourselves in the long run (which makes my teeth itch) since the parent item will inevitably change right up until the last second. The solution is to decompose your backlog items at the last possible moment before the sprint.

Limiting Work in Progress (WIP) and Scrum

WIP and Kanban are things that I hear about more and more every day and it's worth noting that I'm personally a big believer in both. Let me tell you a little story...

Background Story:


My first tech job was building and configuring enterprise servers and racks in a lab (or a factory depending on your definition). It was a blast because of all the neat toys that I got to play with but it was not without problems.

You see, we sucked. Specifically, we sucked at getting things done in a timely manner.

At least by my estimation we sucked, I was only a 22 year old kid at the time though so it seemed possible that I wasn't seeing the bigger picture, but I thought we sucked at making things with anything even remotely resembling efficiency.

As time went on, I started making notes of some of the things that I thought were strange. We were constantly running out of floor space, so we couldn't start new orders and Techs spent nearly 10% of their time waiting for new orders to be brought in for them to work on. At first I thought these two problems should be mutually exclusive, if we've got so much work in front of us that we literally can't fit in the space anymore, then how can we not have anything in front of us to work on?

The Problem:


As it turns out the problem was simple, A rack is put in front of me, I start building it and run into a problem that I can't solve on my own. I then have to make a call to somebody else to fix it and move on to whatever is next because it's no longer my problem. Before you know it, everything on the floor is waiting for some magical fix that I can't provide, there's nothing left for me to actually do and so I sit on my hands and complain that I can't get anything done.

This was all an intellectual problem for me until I was put in charge of a team that was failing, even by our low standards. This team generally got smaller orders which meant we had more opportunity to get blocked on any one of them, which played a big part in their abysmal performance.

The Solution:


I went about the business of fixing this in the only way I knew how: by being loud and annoying (that's what 22 year old Sean did). There were five of us on the team, so I declared that we would only bring 5 orders into our area. We can be working on fewer than 5 orders but at no point do we put a 6th order in front of my team and I got loud and annoying when anyone tried to do otherwise.

This pushed the other side of things, when an order became blocked it became important to unblock it so that we could really finish it and move on. Sometimes it was painful. Really painful. Really Really Painful. A second order became blocked and it was unbearable.

What happened was that when an order became blocked I would pull the tech working on it to whatever I had my hands on, shot off an email and if I didn't hear back within 10 minutes I went on a manhunt. I didn't send emails asking for a solution twice, I didn't wait all day, I didn't make phone calls. If my order was blocked and you were the person that could unblock it, I was at your desk, or at your boss's desk, or your boss's boss's desk and I didn't leave your side until I had a solution. Generally I made my loud and annoying presence known until I got what I wanted (which is what everyone wanted but was simply inconvenient to provide). Needless to say, I caught a little bit of heat for this behavior, but luckily my team had become the single most productive (and profitable) on the floor and it's hard to argue with the scoreboard.

You see what happened over time was that my team spent less and less time getting hung up on random issues and more and more time actually building stuff since we weren't spread over tens of orders. Over time my little forays also became less and less frequent as well since it became obvious that I was going to bug the crap out of anyone that held up my team for more than 10 minutes. What happened is that the business actually learned how to become more efficient at providing for the team.

How it Applies to Scrum and Software Development:


This was before I had heard of the magic of limiting Work In Progress or Kanban or really any of these, it just seemed like a logical solution for a random problem I had encountered.

So why does this apply to software development? While your team doesn't need to worry about floor space they can very easily become inefficient through working on too many things at the same time. What's more, they'll develop a tendency to start everything early but not finish until right near the end of a sprint which can really play havoc with tracking your daily progress.

The takeaway here is that limiting Work In Progress (WIP) isn't really a secret, it's not complicated and it's certainly not even something you need to take a weekend to learn or read a book on. It's just good old fashioned problem solving applied to a really common problem. While floor space isn't something you have to deal with, integrating 10 features into a product in the last few days of a sprint is.

Summary:

Limiting Work In Progress works in the same way that Scrum does. You see Scrum doesn't really solve any problems for you and neither does limiting Work In Progress, it just exposes the problem for what it really is which makes it easier to solve. If it's a business area problem, then it's easy to show and prove to the business making the solution easier. If it's a tendency of the team to juggle the entire sprint backlog, then bring in a WIP limit and measuring over a couple sprints might be enough to prove to them the virtues of this new idea.

If your Scrum team can't solve a problem on it's own, then they come to you (the Scrum Master). It's your job to hunt down whomever can unblock the team as quickly as possible and solve that problem. What will your developers do while you're on your manhunt? Partnering up on a single programming task would work great, maybe having a WIP limit of 8 for a team of 7 or a WIP limit of two for each single developer. Use your sprints to experiment here if it seems like something you want to implement.

Just remember to wear comfortable shoes since you'll be walking a bit more than normal for at least a little while.

5 Big Issues When Scaling Scrum

I think it's a safe bet to say that if you're reading this blog then there is a good chance that you're at least interested in Scrum. The problem is that for many organizations, even the basic concepts in Scrum begin to break down as we scale it up to the entire organization. Imagine a daily stand-up when the development team consists of hundreds of developers and even more testers. These problems are not small and very often can mean the difference between a successful project or a horrific failure. So what are some of the bigger issues at hand? Glad you asked.

1) Testing is done outside of the Scrum Team:
I'm not talking about unit testing (although those should be part of your definition of done). I mean functional testing, done by a testing professional. If you "finish" up a backlog item, run your unit tests, mark it as complete in the sprint and then ship it off to the separate testing group, then you can't really consider it complete until it comes back. The solution here is to embed at least one tester with each scrum team so they can get immediate feedback within the sprint on the completion of a backlog item.

2) Team size is too large:
Amazon has a rule that any team that can eat more than two pizzas for lunch is too large. Now I'm not going to argue the logic behind that argument but that would allow for me and one other similar sized person and 'm not sure that's what they're getting at. The general rule of thumb that I've come across is that a Scrum Team (including testers) should be about 7 people give or take 2. Meaning that 10 people is starting to get a bit large and 4 people (while better than none) might benefit from at least one more. How does that help me with my team of 100 devs? Well obviously we're not going to fire 93 people and expect the results we're looking for. But we will break the team up into smaller teams of preferably 7 give or take a few developers.

3) The daily standup (and other meetings) are conducted en masse: 
Each individual team will conduct it's own sprint planning, it's own daily stand-ups and it's own retrospectives. From there it falls to the Scrum Master to roll all of this up to the meta-team level to combine into the total project as a whole. For instance the small teams all do their daily standups and and get back to work, the various Scrum Masters (or team leads) all get together for a quick standup to briefly talk about their teams progress, issues and goals for the day. The individual team performs their retrospective and identifies some areas for improvement or things to try in the next sprint and the Scrum Master performs a total retrospective with the other Scrum Masters to discuss the total sprint. And so on and so on.

4) Nobody can get ahold of the product owner: 
What happens when the Scrum team is working on a story and discovers that they don't know what a form should look like? That story stops until the Product Owner responds. Scale this up to 100 or so developers and you've got yourself a problem. The solution can be a little tricky, ultimately you'll want a single product to make big/heavy decisions about the product but spread him too thin and his ability to respond will suffer causing the team to wait for answers (which is never good). In large organizations you may find it easier to have a single Product Owner and several smaller Product Owners to assist the Scrum with their inevitable questions.

5) The Scrum Master has no idea what's going on:
Having a single Scrum Master for an entire organization is a bit like asking a single waiter to handle every table in a busy restaurant. The Scrum Master's job is ultimately to serve the needs of the Scrum Team, spread that out among multiple Scrum teams and that service will suffer along with the teams performance. Ideally there should be one (and only one) Scrum Master for every team. They don't need any special certifications or advanced skills, just a basic grounding in Scrum, good old fashioned common sense and a good grasp of what the Scrum Master does all day.

These are just some general guidelines and issues that I've seen with large groups adopting Scrum. There's certainly other issues that you'll run into and different solutions that you'll try. Let me know about your experience in the comments, I always love being exposed to new problems and new solutions.

I'm doing an introductory Agile webinar soon

Enough of our customers at Axosoft have asked us for an introduction to Agile and Scrum that I went ahead and put together a brief webinar that should act as a decent primer. Chances are if you're at this blog then the material I'll be covering won't be new to you but this should serve a great introduction for any co-workers of your that are still a little leery of this whole "Agile" and "Scrum" business.

We're planning for Thursday May 19th from 10am - 11am PDT. Only about 30 minutes will be canned speech the rest will be a general Q & A about Scrum and Agile.

Check it out at Axosoft.com

Sign up to attend with this LINK

Sprint Lengths and Long Releases

If you're not careful, the length of your sprints may become a one size fits all solution wherein you try to shoehorn every development effort into a 2 week iteration or some other length. I try to caution people from reaching this point for a number of reasons.

Certainly, having a shorter sprint size has it's advantages because the shorter time frame allows for more accurate planning, faster feedback and a bit faster pivoting for the team. There's another side to this as well though, before every sprint you have to have a sprint planning meeting. Ideally your developers will estimate (or reestimate) their work items right before the sprint. Before you plan the next sprint, you need to review the sprint and perform a retrospective. All of these things are good and should be done between each and every sprint, but they also mean time that the development team is spending away from more important things, like development.

And therein lies the conundrum. Traditionally you would try to reach some kind of happy medium for sprint length and that sprint would become the heartbeat of iterations for your software. Every 2 weeks, 3 weeks or 1 week you would finish the sprint and there would be a new potentially shippable iteration of the product. This is good, many teams will start doing this and will likely continue because it works great, but don't let it become a rigid law for your organization.

But here's a thought: no Scrum rules should overcome a thoughtful decision made by an intelligent person (which I'm assuming you are). Which is to say, we should protect the team from being overburdened by the Scrum Framework.

What if we were working on a long-term unannounced project? Perhaps it's a AAA game title or an entirely new product with a deep feature set. In either case, customer feedback isn't that useful since our customers don't even know the product exists. Moreover, for at least the first few sprints, the development team's focus will be more towards achieving a minimum viable product.

This doesn't mean that we throw Scrum out the window, in fact just the opposite. Sprints, retrospectives, planning and the product backlog become even more important. Since this specific article is about sprint length we'll start there.

If this is a new team working together for the first time, short sprints are probably best so that we can loop back in often for retrospectives, maybe a one week sprint or so (shorter or longer, it's up to you). Tuning a team to work together will make your life much easier on the long road to the release.

Once the team is comfortable working as a unit, those retrospectives (while useful) can be seen as overhead if they're done too often and since the product backlog primarily consists of Minimal Viable Product work at this stage, priorities are unlikely to shift too often. As we begin to settle in for a long release you can lengthen your sprints (every two weeks or every month). You'll still track your daily progress via the burndown chart and your daily standups, but will loop back in to finish the sprint less often.

Once you begin closing in on a release, feedback becomes important again, functional testing will provide new insights, tweaks on the original design are made, beta testing will finally allow for customer feedback, etc, etc...

Because of all the new feedback as we get closer to a final release, it can become important to shorten up the sprint length again to allow the team more room to change direction and priorities between sprints.

Using variable sprint lengths are probably not the norm and is usually reserved for longer development cycles with a minimum amount of customer feedback, but ultimately the sprint length is a tool for the Scrum Master to experiment with and use to the development team's advantage.

What are some of the things you've noticed about how sprint length affects your team?

The Daily Scrum Stand-up is Not a Meeting

One of the bigger complaints that you'll hear from Scrum Teams is that the daily scrum stand-up meetings are a chore. Upon further investigation you'll probably find a few commonalities.

Problem: The Daily Standup is a meeting

What do you call it when a bunch of people leave their desks to gather in a room to talk about something? It's not a stand-up (even if you're all standing), that's a meeting and it typically involves a lot of waiting for everybody to get there.

Solution: The Daily Standup is not a meeting

The entire team should fit into a single room (team size is another post). The Scrum master walks in the room (preferably at a known time) asks everyone to standup, we go around the room chatting about progress and problems and everyone gets back to work within 10-15 minutes unless something really interesting comes up. If an important stake-holder, Product Owner or anyone other than a team-member isn't there then they'll miss it.

Problem: The Daily Standup kills productivity

Imagine you're changing the oil in your car, you're wedged underneath the engine, elbow deep in the bowels of the vehicle just getting ready to pull out the oil filter (try to imagine if you've never actually done this before). Now imagine you have to drop everything, walk away from the car altogether to tell everyone about your progress on the oil change. Now you get to ease yourself back under the car, wedge your arm back up to the oil filter and start over again. If this were a daily thing then I'd start to get annoyed as well.

Solution: The Daily Standup happens quickly and early

Ideally the standup should happen first thing in the morning and before anyone starts in on their tasks for the day. In practice this doesn't always work since developers may come in at different times. Try to make the standup as early as possible before any serious work gets started.

Problem: Nobody pays attention at the Daily Standup

We're all here, doing the daily standup, each team member is taking turns telling everybody the details of what he did yesterday. Twenty minutes later, pretty much everyone has their phones out and not a soul is paying attention. We've now lost essentially 1/24 of a workday to an essentially useless Scrum Excercise

Solution: The daily standup is quick and/or interesting

"I fixed that date/time conversion bug yesterday, and I was gonna grab that sorting speed task today." "Ran into an issue with the search sproc yesterday, it was only returning a max of 400 results, got that sorted out and I'll be finishing up the search task for the user admin page today." Now imagine that happening for every team member on a 7 person team. The standup goes pretty quick doesn't it? The only time the meeting should go long is if somebody has a very interesting problem at which point the developers may spend some time discussing it. The standup should be either very short or very interesting but not boring. If it is boring, it's your fault (as the Scrum Master) for not educating the team in how to use this time.

Bottom Line: The daily stand-up is a major part of building a great Scrum team provided you don't screw it up by turning it into another corporate event. The stand-up centers around the Scrum team and nothing else. It's small amount of time (emphasis on the small) for the Scrum team to center in on their progress, goals and issues that are important to them. Anything else you do during the stand-up amounts to overhead.

What does the Scrum Master do all day?

The Scrum Master doesn't plan the release, that's done by the Product Owner and the Scrum team.

He doesn't manage the developers as the Scrum team is self-organizing.

He's not even the guy that gets his neck wrung if the end result sucks or doesn't come together (that's the product owner).

If the product owner is the head that makes the decisions and the Scrum team is the arms and legs that do the work then the Scrum Master is the ooey gooey insides that hold everything together.

So who is the Scrum Master and what exactly does he do all day?

Simply put, the Scrum Master is the guy that manages the Scrum part of development. That means our Scrum will probably have at least these things on his plate:

• Facilitating the daily standup (but not participating)
• Helping the team maintain the burndown chart
• Setting up any retrospectives, sprint reviews or sprint planning sessions
• Shielding the team from interruptions during the sprint
• Removing obstacles from the team (that they can't remove themselves)
• Guiding the Product Owner in his/her role
• Encouraging collaboration between the Scrum team and the Product Owner

You'll notice a common theme here. Essentially anything here that ties back to Scrum is directly tied to the Scrum Master or the Scrum Master will provide guidance. The point here is that the Scrum team will not overly concern themselves with Scrum and will mostly focus on the job of software development and the Product Owner likewise will focus on the stakeholders and business needs so they'll lean on the Scrum master to guide them in what's needed for the next iteration.

If this sounds like a full time job, that's because it is. The responsibility of the Scrum master is to make certain that Scrum doesn't get in the way of development or customer feedback which will take all of their time. That being said, not every Scrum Master is "just" the Scrum Master. Some teams may choose to elect a developer or tester to become the Scrum Master for the team, this shouldn't be considered the norm but it does occasionally happen so don't feel bad if you discover after your first couple sprints that your Scrum Master just doesn't have enough to keep him busy. Here might be some reasons why that is:

• Your product owner knows his customer inside and out and is always there for the development team without guidance from the Scrum Master.
• Your Development team has such a healthy communication culture that a daily standup is redundant and adds to the overall process overhead.
• The burndown chart and other artifacts are maintained automatically or otherwise incur no overhead on the development team.
• The team operates free of distractions and can clear all obstructions on their own with minimal overhead.

If these don't describe your team (or even if they do), separate out a Scrum Master for the team for at least one sprint before deciding one way or another how the Scrum Master will fit into your next sprint.

What's the Deal with Story Points when Estimating?

About a year ago, a buddy of mine asked me to help him install a car stereo he just bought and I readily agreed provided the beer was provided and my wife would let me out to play for the weekend. We sat down to figure out everything that needed to be done, took into account our expertise (I'm handy with a multi-meter and graphing calculator and my buddy has spent some time working on his car before), so we felt like we were over-budgeting when we said we could get it done in a weekend. Should be plenty of time.

Three weekends (plus a few weekdays), a very angry wife and a disheveled garage later we finally put the faceplate back on, plugged the battery back in, powered up the fruits of our labor and it was good. The problem wasn't that we couldn't do it or that we didn't have the resources or even that we didn't have the time. The problem was actually very simple, we hadn't done it before so of course we couldn't estimate our time correctly.

Chances are that you have a story that is at least a little similar to this. I want you to stop and think about that the next time your sitting down with a developer to discuss the number of hours they'll need to fix a bug that they just learned about 10 minutes ago.

See where I'm going with this?

Force an estimate out of a developer with a definite value and you're going to get one of two things:

• A thoroughly underestimated work item


• A thoroughly padded estimate

Neither of which is useful in the slightest when it comes to planning a successful sprint. Things get even worse when you consider that a bug might take a senior developer 2 hours to fix whereas that new intern may spend the entire day plugging away at it. We need a better way to estimate if we're going to have a successful sprint.

Let's loop things back in with that developer who's estimating.

Let's ask our developer to rate a bug from 1 - 10, 1 being "Easy" and 10 being "uninstall realplayer for good this time". That's the kind of thing that's hard to pad an estimate for since a developer who rates a bug at an 8 will probably take the same amount of time for something else rated at 8 later on. More importantly this gives us an average that we can actually normalize over a team while developerA may take 10 hours on an 8 Story point work item (on average) and developerB may take twice that long (on average) by averaging things out we're able to come up with a reasonable workload for the team over the duration of a sprint without stressing about dev-hours.

So we've got the basic concept down, hours are inaccurate and create false expectations which lead to even more inaccurate estimates which in turn leads to ulcers for everyone involved. Story points offer us an abstraction layer but the way we've been talking about still has some problems.

What happens when we get a work item that rates higher than the last 10 we implemented? We need to remove the upper limit from the scale and it'd also be nice to have an increment so we're spending time arguing among the team if an item is a 7 or 8. So story point estimates should be open ended (within reason, if something is too big then break it down to create smaller work items to plan with). We should also increment story point estimates, which is most commonly done in fibonacci numbers. This means that I can estimate a work item as 1, 2, 3, 5, 8, 13, 21... story points. The bigger an item is, the less accurate the scale so we move in bigger increments.

We now have a scale to plan with, we planned 100 Story points worth of work last sprint and failed miserably. We finished enough work items to total 80 story points so we'll plan that for the next sprint.

Each team will have a different scale of story points, teamA may estimate a work item at 21 story points and teamB may estimate at 13. TeamB isn't faster, they just think of story points differently. On the flip side, Team A may finish 1000 story points worth of work in a sprint and team B finishes 300, once again, team A isn't faster so much as they simply tend towards larger estimates. Focus on having the team estimate and commit to their own work since an estimate means next to nothing outside of the team and coach the team to base what they commit to in a sprint off of past performance (if you don't have any info on past performance then your first sprint will suck, but that's okay ).

And that's it, remove hours from the discussion when estimating and planning a sprint, focus on complexity and past performance and the team when planning a sprint and you're good to go.

Do you have to use story points to plan a successful sprint? Heck no, plenty of Scrum teams estimate in hours and have great success, in fact, check out THIS article our CEO at Axosoft wrote on Scrum. Among other things he lays out a way to estimate without story points and it works great. The point here isn't to tell you the right way or wrong way to do thing (as if such a thing could exist for a development team), the goal is to put another tool in your hands to fix problems that might arise.