Is the bug to the left a large bug or a small bug?  It looks HUGE to me!  Well, in reality it is probably between .5 and .75 inches long.  Not really a very big bug at all.  Why do we care? Because trying to size the fixing of software “bugs” is at least as hard as figuring out how big this bug is!

When I teach an Agile or Scrum course someone will almost always ask a question like “How do you handle bug fixes in iterations or sprints?”  When I ask “How do you want to handle them?” we get into a pretty interesting discussion.  Most people say something similar to “We should prioritize them with the user stories, size them like we do user stories and then see what fits into each iteration.”  I usually smile and ask any developers if they know ahead of time how long it will take to fix a defect.  They ALWAYS say “Sometimes.”  And THAT is the problem!

How can you actually determine the size of fixing something which is broken in an unknown way?  I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!  If those are the only two sizes available to us how can we possibly put them into iterations effectively?

I have found one effective solution to be the use of Kanban techniques for defect fixing.  I don’t want to get into what Kanban is or isn’t and when it should or shouldn’t be used, so I’ll just lay out what I have seen be effective for a number of teams:

1. Prioritize the defect list.  This is NOT done in the context of user stories, but separately.  The list is prioritized however the Product Owner says it should be prioritized.
2. The team and Product Owner decide on how much effort (time) should be used each iteration to work on defects.  Hopefully this is not a large amount, but it might be for teams which have large numbers of defects in a legacy system.
3. The team determines when the defect fixing time occurs and how they do it. Most effective is to put a gate or two in place on the defects.  For example, gate 1 may say the developer needs to know within 2 hours if the defect is going to take more than a day to fix.  If so, then put it off until a discussion can take place with the Product Owner.  Gate 2 may be after a day if the defect is not fixed perhaps another discussion needs to take place.  However the gates are set up (if they are)  the defects are worked in priority order.
4. Limit the number of bug fixes being worked at one time to a very small number.  If you don’t do this you will have each developer working on at least one defect and run the serious risk of none of them getting fixed before the iteration or sprint ends!

This 3 step approach allows the team to work on defects in priority order while allowing a set amount of time to be spent on the defects.  The amount of time spent can be changed as needed to address the business needs of the organization at any point in time.

The downside of this is no one can tell a stakeholder something like “that bug will be fixed by date X” or “we’ll knock out X bugs this iteration.”  Saying anything like that is a lie anyway, so this shouldn’t be a big issue.  I say these statements are lies under the assumption the defects are non-trivial.

How else have you managed a defect backlog that has been effective?  I’d love to have more proven techniques for people to experiment with!

Until next time my clients will be Making Agile a Reality^® by using sizing only when appropriate!

Related posts:

1. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
2. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
3. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...

Earlier this week I posted a blog entry “Agile antipattern: Burndown charts that hide the truth” which dealt with one way a burndown chart could hide reality.  This blog entry shows another way it is possible for a burndown chart to be misleading.  The burndown chart to the left is actually pretty common, especially for teams just starting with an agile process.  In this case it looks like no progress is made for quite a period of time, then everything suddenly gets completed.  Even though this team completed all the stories in the iteration it is still an unhealthy burndown chart.

In this particular case the team had filled their iteration with “large” stories.  Notice the stepped nature of the chart.  A very healthy agile team will usually complete stories nearly every day of the iteration which leads to a chart with a downward slope, not a stepped type of line.  When I see steps like this I worry about the size of stories.  In this case there is a second factor which almost certainly points to the stories being too large: no stories are completed during the first 4 days of the iteration.  Taken together these factors almost always point to stories that are too large.

Specifically what do I mean by stories being too large?  I usually instruct teams to take their iteration length in work days and divide by 3.  The resulting number is usually a good number of days of work to average on a per story basis.  So, for a 10 working day (2 week) iteration if stories average getting completed in 3-4 days (people days, not calendar days) then they are the right size.  Because more than one person should be working on each story (you are swarming, right???) this means stories will be completed almost every day.

As the average size of a story gets larger the ability to complete a story every day is compromised.  For example, if the average story creeps up to 6 days, even with 3 people working on each story it means the average story will take 2 calendar days to complete.  In other words we’ll be completing stories every other day, not every day.  Certainly some can be completed in a day, but others will take 3 days (so the average stays the same).  This gets worse if the number of days to complete a story creeps even higher.

Why is this such a big deal?  Because larger stories tend to get harder to complete within the iteration when they are started later in the iteration.  An image I use in my courses is one of a Tetris game.  Imagine you have built up some blocks (completed stories) and there are now holes which are certain sizes.  Do you want large complicated shapes to fall, or smaller, simpler shapes?  Of course the small, simple shapes are easier to deal with just like it will be easier to deal with smaller stories.  The more complicated the shapes later in the iteration the harder it is to make them all fit and the more likely we are to fall short of our commitment.

Teams fall into this trap quite easily.  If a team has 8 members and velocity for the team is 40 it seems like the team can complete 3 stories of size 13 and 1 story of size 1.  That adds up to 40 so it should be possible.  Unfortunately, the 3 large stories make this scenario very unlikely to be successful.  If 2 people work on each story then the size 1 story gets completed very quickly, but only 6 people can work on the 3 large stories while 2 people sit around and do nothing.  Team capacity is wasted which means the stories won’t get completed.  If we say 3 people can work on a story then we still have the problem but in a different way – now we don’t have enough people to finish the large stories which are each 1/3 of the work in the iteration (we would get 2 of them done but then just have 1/3 of the iteration to get the other done).  As you can see, big stories can cause big problems.

Now that we know we have a problem, we have to solve it.  A typical planning poker deck of cards contains some very large numbers.  For this reason teams seem to think they have to use those numbers.  DON’T!  In fact, the fix I would suggest to stay away from large stories is to burn all cards higher than a 13 (maybe even 8 and higher) and never use them during planning poker.  If a story is larger than your new largest size, split it.  Oh yeah, you don’t know how to do that part.  That’s ok, read my next blog entry which will be on splitting stories!

Until next time I’ll be Making Agile a Reality^® by burning lots of planning poker cards!  I hope you do too!

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...
3. New to agile? Learn how to split stories In my last blog Agile antipattern: Taking on large stories I said I would...

I recently saw an excellent blog post about iteration velocity.  Good reading in general, but the last paragraph really got my attention and is why I’m writing this blog post.  Do NOT compare velocities between teams!  All teams will size (or estimate) with a slightly different scale.  When I teach a course on agile I tell teams to size using points, not hours or ideal days (a blog post for another time).  This means each team determines for their situation what a size “1″ and all other sizes will be.  They are going to be different.

If you start measuring teams against each other by comparing velocities you will get what you measure.  Teams will start changing their scale so their velocity increases each iteration.  Suddenly what was a size 1 last iteration is now a size 3 (or worse!).  Don’t fall into this trap.  If teams are working hard, meeting their iteration objectives and keeping the product owner happy I don’t care if their velocity is 10 or 10,000.

Until next time I’ll continue warning managers about this practice so it won’t adversely affect their teams which are Making Agile a Reality™.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. New to agile? Don’t settle for mediocrity James Shore recently changed the entire focus of his company. This blog...
3. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...

As an agile trainer and coach I often see new teams struggle with a simple question: “How much to do on a user story?”  A lot of people say the simplest thing that works is what should be implemented.  I agree with that wholeheartedly and even have a blog entry on how to figure out what the simplest thing is.  Unfortunately, lately I’ve found myself adding a bit to the sentence.

Do the simplest thing that works - THEN STOP!

There are developers who do the simplest thing that works and then keep going because they think the customer will want something more.  While they may be right, it isn’t their decision to make at that point.  Show what the team created at the iteration demo and see if the feedback from the demo says more should be done.  Don’t just assume it!  The extra work costs time and money, not to mention ongoing support costs if it actually goes to production.  The Product Owner needs to take all of this into account when deciding how far to take a story.

Oh, and while we’re on the topic, if you want to know how to have a great demo, read this blog entry.  It has some awesome ideas that all teams should try to follow.  The only thing I would add is to have someone other than a developer or tester be able to try the software during the demo.  Too many horror stories about how things were missed when developers went through demos too fast!

Thanks for reading this.  Until next time I’ll be helping teams in Making Agile a Reality™ by putting up a stop sign when they start trying to gold plate features!

Related posts:

1. New to agile? Keep it very simple When dealing with an agile implementation, particularly in the case of a...
2. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
3. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...

People who promote the use of Planning Poker understand some of the main reasons why it is successful.  People like Mike Cohn have been very instrumental in pushing planning poker and even created www.planningpoker.com for people to be able to play planning poker with distributed teams.  There are very good reasons why most agile trainers and coaches (myself included) promote its use. 

My personal top 3 reasons planning poker is great are (all of these assume the team is using planning poker appropriately):

1. Fosters collaboration by engaging entire team
2. Creates consensus estimate rather than having a single person driving the estimate
3. Exposes issues early through discussion of each user story

All of those are great reasons to use planning poker, but there are also some ways to help make it work even better.  The three items listed above are all very obvious if you watch successful teams using planning poker.  But there are small things most people miss which can be done to improve the process.  Knowing of those things allows successful coaches to help teams get even better.  The beauty of it is you don’t have to be a coach, just someone the team trusts, to help the team get better.  So what are these nuggets of wisdom?

1. Those who actually could do the work are the ones that vote.  Too often agile teams have everyone vote even if they have no idea about the work involved in the story.
2. Managers don’t vote.  Managers are usually incented to have the work take less time, so they often skew the vote too low.  However, managers have more experience than the average team member, so I usually give them veto power over the team consensus in one specific circumstance – they can ask the team if they have considered something which may INCREASE the size.  They are never allowed to try to get the team to decrease the size.  Their opinion carries too much weight and acts as an anchor to the size, dragging it down in direct propoportion to how vigorously they defend their position.
3. When there is a tie in the voting between two sizes which are consecutive, just pick the larger size and move on.  Remember, consecutive sizes might be 5 and 8 if you are using the Fibonacci sequence for sizing (1, 2, 3, 5, 8, 13).  No one should complain about using the higher number and an equal split usually takes a long time to resolve.  It also usually resolves to the higher number, at least in my experience, so let’s use those facts to our advantage and move on.
4. Stop implementation discussions before they go too deep.  Teams commonly drive down to the technical details when they are discussing a user story.  This is fine to a certain extent, but it should be severely limited.  No more than a one minute discussion.  The people doing the sizing should determine in their mind the simplest possible solution and pick a size based on that scenario.  It seems like more discussion will make the size more accurate, but in reality this just isn’t true.  The scale is not very granular so there is a distinct lack of precision.  This is done partially to encourage teams to just make their best guess and move on.
5. Use an “I need a break” card.  Too often teams will be working hard playing planning poker and not realize some people on the team need a break.  Having the “I need a break” card allows someone to draw everyone’s attention to this.
6. Use a timer of some sort to limit discussion.  This is self-explanatory.  I usually like to limit discussions to no more than one minute.
7. If consensus cannot be reached by the end of the third round of voting pick the largest size and move on.  After two rounds of discussion further discussion usually does not yield great results for the time invested.  By choosing the largest size the team has a chance to improve upon it, but they will not be in any danger of not having enough time.  Not having enough time is a major problem the team is trying to avoid, so this particular short cut should not cause major issues.
8. Have the person creating the user stories meet with QA and Development leads prior to playing planning poker to make sure the user stories have answers to the most obvious questions the team will ask.  This allows the team to focus on the size, not spend time gathering information.
9. Remember the baseline.  Whatever the team picks as a baseline needs to be consistent from iteration to iteration.  If an ideal day is a size 1 then all iterations need to use that reference point.  If a particular user story is a size 1 or a size 3 then that needs to remain consistent across iterations.  It can sometimes be helpful after a few stories have been sized to bring up the baseline and ask the team if they agree the sizes are truly relative to the baseline.  Failure to do this could lead to what I’ll call “size creep” over time.  In other words the team slowly changes their baseline mentally to be either larger or smaller than it truly is.  This usually shows up as the team not being able to meet their commitment for several iterations even though everything looks more or less the same.
10. Have fun!  Playing planning poker should be a fun, collaborative exercise.  Too many teams try to grind it out for an hour or two and forget to enjoy their work.  There are many ways fun can be injected into the process.  One I particularly like is to play real poker with the sizes.  Every sized story counts as a poker card and every five stories makes a poker hand.  Prior to starting everyone tries to pick which hand will be the best poker hand (i.e. pick hand 1, hand 2, hand 3, etc.).  This encourages them to look at the user stories ahead of time so they can try to make a good guess about which set of 5 will make a straight or 4 of a kind.  Winners can even get a small prize.

Give these tips a try and see if they help your team.  Until next time I’ll be Making Agile a Reality™ by helping teams play planning poker!

An expanded version of this blog entry appeared at the Agile DZone http://agile.dzone.com/articles/introduction-planning-poker.  That article has now been translated into Japanese and can be seen at http://pub.ne.jp/Under_the_Bridge/?entry_id=2762950 (thanks to Tetsuji Maegawa for the translation!).

Related posts:

1. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...
2. New to agile? Learn how to split stories In my last blog Agile antipattern: Taking on large stories I said I would...
3. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...

I’d be rich if I had a nickel for every time I’ve heard this, or something very similar to it, in the past 30 years!  Alright, that’s taking it too far, but I think I could at least afford a really nice dinner out with my family on the amount I’d have received.  But that isn’t the point.  The point is anyone thinking this statement is a valid excuse for poor results is wrong on several fronts.

Before we go any further, if the title intrigued you, immediately click on the image to the left and purchase Mike Cohn’s bible about agile estimating and planning!  If you don’t own this book, then I now know why the title of this blog post made you look further! 

Now, back to the issue at hand and why it is wrong to think this way.  First of all, this type of statement is part of the reason a waterfall model doesn’t work.  In the waterfall model it is typically development leads or other managers giving the time estimates.  This isn’t a written rule for a waterfall approach, but it seems to be given how often I have seen it in my career.  Let’s think about it for a second and see why this is the wrong way to approach things.  Is the development lead rewarded when a lot of software gets completed?  If so, this incentive is at least subliminally causing them to cut time estimates to the bone.  Is the development lead more experienced than most members of the team?  If so (and I hope the answer is yes!), then he or she is likely to estimate for their rate of development, not the rate of development for an average team member.  Does the development lead have enough clarity to actually give a meaningful answer?  If yes, great, but in most cases the answer is no.  Again, this leads to an estimate which may be on the low side due to a lack of knowledge about specifics.  So just from a logic point of view, using a model where the development lead estimates time is bad.

Second, on agile teams some goals are to collaborate well, and be held accountable for results.  If this is true (and it is), then we are completely bypassing both of these.  We are not allowing the team to collaborate to come up with an estimate they can live with.  Further we are holding them accountable to a result when they were not given the opportunity to give input.  We are back to waterfall where someone says we need x by date y and I told with Joe and he said we could do it, so do it.  That isn’t agile, that’s lunacy!

Lastly, we have taken a single data point and assumed it is 100% accurate at the start.  Even in a waterfall project it is well known that accuracy of estimates at the beginning of a project vary widely.  Review the cone of uncertainty to learn more about how bad it can be.  Part of our goal in agile is to deal with the cone of uncertainty by iterating toward a result.  So to add insult to injury, we assumed the estimate was correct, and we didn’t check on it each iteration to deal with reality.  How not agile can you get?

Project managers are starting to recognize that estimating is different in agile.  This blog post from PM Toolbox is just one example.  There are many more things to consider when estimating.  For example, things sometimes get more difficult at the end of a project (or at least development slows down).  There is a reason the 80/20 rule is often cited!  There are lots of ways to estimate, and lots of ways to do it poorly.

The bottom line is the worst thing anyone can do is ask a development lead to estimate something and then hold an agile team accountable to the estimate.  Collaborate and use planning poker to create estimates and you will be a lot happier in the long run.  There is even planningpoker.com for teams that are distributed! 

Time for me to get ready for a trip to Boston where I’ll be starting down the path of  Making Agile a Reality™ for another client.

Related posts:

1. Agile antipattern: Insanity! (5 insanity antipatterns) It is sometimes said the definition of insanity is doing the same...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...