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. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
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...

What’s wrong with the user story on the card?  It seems to have everything we need: a) short title, b) a size (in this case 2), and c) a well-written story using the standard “As a … I want … so that …” format.  So what’s wrong? Nothing!  Well, almost nothing.  The user story card is a great STARTING POINT, but it is not sufficient by itself.

In coaching Agile and Scrum teams I see many of them starting out with the assumption that the user story card contains all the information they need in order to create a high quality piece of software.  Forgive me for being harsh, but how stupid is that?  Assuming a single sentence can fully describe something which might take a few days to analyze, design, code and test seems pretty ambitious.  No, let me take that back.  It’s more than pretty ambitious, it is just not possible. So I ask again, what’s wrong with this story card?

And again I’ll answer that there is nothing wrong with it, but it is a STARTING POINT.  Many people are familiar with the phrase “INVEST in good user stories” which is an easy way to remember to use the INVEST acronym for guidance when creating user stories.  I wrote a blog entry about that titled “New to agile? INVEST in good user stories“  Web searches lead people to that blog entry many times every day.  But it isn’t sufficient!  If you read agile literature for any period of time you will eventually see the phrase “A user story is an invitation to a conversation.”  This is vitally important to success!  A conversation allows more description than a single sentence.  It can clarify many aspects of the user story.  Taking this a step further we also need to be able to confirm the user story is completed.

Taking all of this together we end up with the 3 C’s of good user stories: Card, Conversation, Confirmation.  Ron Jeffries wrote about this all the way back in 2001 and his advice is still good today.  Agile and Scrum teams need to remember the card is the starting point.  It leads to a conversation where more specifics are given and negotiation (the N in INVEST) can occur.  All of that leads to confirmation in the form of tests (the T in INVEST).  A good story card will likely end up with a back side covered with results of the conversation(s) and confirmation tests.

Next time you see a user story card don’t ask yourself if you need to have a conversation about it.  Instead just assume you need to have a conversation and have it!  Go to the Product Owner or customer or customer proxy and ask to discuss the story.  Make notes for yourself.  In fact it is even better (vital in my mind) to have the conversation involve a developer, tester and product person.  I call them 3-headed conversations.  This allows everyone to be on the same page so later there is no disagreement about what was really meant by the story.  This avoids one of my least favorite conversations which happens when the tester and developer disagree about what the requirement means AFTER the code is written.

If you are using an agile lifecycle management tool rather than physical cards, record the decisions made during the conversation and any resulting confirmation tests in various fields in the tool.  You must make sure the information is captured in case someone else who was not part of the original 3-headed conversation ends up doing some work on the story.

Try using the 3 C’s and see if your results improve.  I’m sure they will.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to train and coach them to use the 3 C’s effectively.

Related posts:

1. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
2. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
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...

In my last blog Agile antipattern: Taking on large stories I said I would give you some tips on how to split stories.  First though, it is important to understand WHY splitting a story well can be helpful.  It is about much more than just making smaller stories.  In fact, making smaller stories may be the least important part of splitting stories.  The most important aspect of splitting user stories is to help make sure the team can be successful.  However, that statement has a lot implied in it.  We need to dig a lot deeper to expose the real reasons for splitting user stories and not just do it as a good practice (we must BE agile vs. DOING agile).  Not that it isn’t a good practice, just that there are more reasons for doing it!

How can the team be more successful by splitting large stories?  Well, my last blog entry on taking on large stories makes it clear one advantage is stories will fit better into an iteration when they are smaller.  But I said making them smaller was not very important, so there must be more to this than meets the eye, right?  Yes, there is!  Below is a list of 10 reasons why splitting large user stories will help teams be more successful.

1. It may be possible to split a story so some of the work on the original story doesn’t have to be done.  Ding, ding!  Huge productivity improvement!  Lean principle alert – eliminate waste!  This reason is good in some many ways you can’t even begin to count them.  Any time work can be eliminated without affecting the overall value of the product it is a good thing.  Oh, and if after splitting the story we see we don’t need to do any of it, well that’s just AWESOME!
2. Stories can be split to expose more personas.  Sometimes teams see a story as large because there are many different types of personas which must be taken into account.  The story becomes easier to deal with, and we gain clarity, when we see the personas split out separately.
3. Stories can be split to help expose risk.  We may have user stories which have elements of risk in them.  If we can split the user story to isolate the risk we may be able to avoid the risk altogether.
4. It may be possible to split a story to ease a transition.  When we upgrade existing functionality we often give users a bit of a shock.  Sometimes we can split stories to give a smaller shock up front and postpone other work until a later release.
5. A split story may be able to have more people work on it at once (swarming).  If a story is large and requires primarily one type of expertise we tend to let a single person do all of that type of work.  However, a split story may enable others to chip in because some portions of the large chunk of work can be handled by people with less expertise.
6. Splitting a story may give us more visibility into its true size.  I have seen many teams split a size 13 story into 3 pieces and end up with 3 stories each of size 8!  In fact it isn’t even that uncommon.  When we have an upper bound on our story size we tend to use that size for anything “big.”  This leads to large under-estimating for truly large stories.
7. A story split may allow us to use a different quality standard for the new stories.  A simple example in a reporting system may be two of the same type of report, but one is run hourly and one is run yearly.  The hourly report may need higher quality than the one run yearly.  This may be a bad example, but I think it gets the concept across.
8. When a story is split correctly it can help with testing.  Some portions of the story may require full end-to-end testing, while other portions may be able to be tested in a mock environment.
9. A split story may isolate performance factors.  One portion of the original story may affect performance while another does not.  This may affect prioritization as well as performance testing time.
10. Of course, splitting stories may just make the original story be in more digestible chunks so they fit better into iterations.

Those are all good reasons for splitting user stories, but I haven’t really told you how to do it.  That’s because I don’t have to.  My good friend and fellow founder of the Agile Cooperative, Richard Lawrence, recently had a blog entry on Patterns for Splitting User Stories.  He explains it much better than I ever could!  In fact, he explains it so well that Dean Leffingwell is going to be using Richard’s work in his next book.  High praise indeed.

Until next time keep Making Agile a Reality^® by splitting those large stories!

Related posts:

1. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
2. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...
3. Agile antipatterns: Agile burn-down chart roundup post Do you want to see several different ways agile and scrum burn-down charts...

Over the past 18 months I’ve encountered a number of teams where it is standard practice to have a code freeze late in the iteration.  The reason given for this was “to allow QA to test what we created during the iteration.” I’m sorry, but I have to be blunt here – this isn’t agile! It leads to 3 main questions:

1. What are the developers doing after the code freeze?
2. What happens if defects are uncovered after the code freeze?
3. Why could testing not be done earlier in the iteration?

The answers to these questions are often enlightening.  Let’s take them one at a time:

1.  What are developers doing after the code freeze?

I’ve heard two primary answers to this.  The first is that developers are fixing defects during that time.  When pressed, I usually find out these are defects from earlier iterations (although this isn’t always the case – more on that later).  If we are fixing defects from previous iterations while QA is working on testing the current iteration, how do we ever get caught up?  Maybe I’m being a bit dense, but I just don’t see the math working on this one.

The second most common answer is developers are working ahead on things for the next iteration.  Said a different way, developers are creating yet more untested code before the commitment for the current iteration has been met.  Let’s think about this model for just a minute.  Let’s assume we are in iteration 1 and the team does a code freeze on day 7.  Coding occurred for 7 days and testing will go for 3 days.  But the developers start stuff from the next iteration on day 7, so for the next iteration they get 3 days from this iteration and 7 from the following iteration for a total of 10 coding days, followed by 3 testing days.  This cycle continues until the project completes.  Anyone feeling sick yet?  Again, being blunt, this is not agile, it is mini-waterfall or what I prefer to call “wagile.”

2.  What happens if defects are discovered after the code freeze?

Again, in Family Feud style, the most common answer is the defects are fixed in the following iteration.  This is a continuation of the first half of the previous answer.  How can the math ever work?

However, this isn’t always the answer.  Sometimes the answer is developers fix them as they are found.  This answer is MUCH less common, but does exist.  The problem with this answer is very simple: if it is possible for developers to fix defects in real time after the code freeze, why could this not be done earlier in the iteration?  Which leads to question 3…

3.  Why could testing not be done earlier in the iteration?

Two answers here are equally common.  The first I’ll cover is the “it takes too much time/effort to move the code to our QA environment so we only do it once per iteration.”  I understand the need for a QA environment for testing, but is it necessary for ALL testing?  In most of the cases I’ve seen it is possible to do a tremendous amount of testing in a development environment to make sure everything is basically working before promotion to a QA environment.  The QA environment should be renamed the Verification environment.  Ideally we want to use it to verify everything works in the stable environment and passes all tests just like it did in the development environment.  So step one is to do more testing in the development environment.  Step two is to use some automation tools to build a stable environment quickly.  When pressed, most teams can create an automated process to do a bare-metal environment build within a short period of time.  It is worth the effort.  If this exists, a new build could be deployed at any time, but at least nightly.  Combine it with automated regression testing and really get some value from it!

The second answer I usually hear is “we don’t know what to test until the code is done anyway.”  Uh oh, can anyone even count how many ways this statement isn’t agile in nature???  Let’s remember the agile process:

1. Product Owner (or similar role) creates stories and some basic acceptance criteria.
2. During iteration planning more acceptance criteria are created based on conversations between tester, developer and Product Owner.
3. During iteration the developer and tester collaborate on their understanding so the code can be written and acceptance criteria can be turned into tests.
4. During development the developer can (and should) access any acceptance tests already written to see how their code is doing.
5. The developer isn’t “done” until the code passes all unit tests and acceptance tests.  Remember the definition of done!

When things are done in this manner the tester ALWAYS knows what to test because they are in close communication with the developer.  Collaboration is vital to agile success.  This is just one example driving it home.

The bottom line for me is there is no legitimate reason for having a code freeze during an iteration.  Teams need to either invest the time/effort to put together a system which doesn’t require a code freeze, or stop calling themselves agile.  This is a nasty antipattern which will cause confusion or worse.

Thank you for reading.  Until next time I’ll be Making Agile a Reality™ for my clients by helping them avoid code freezes during iterations.

Related posts:

1. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...

Many companies adopting agile have a hard time with the architecture and design of their large systems.  They like the concept of agile, but can’t understand how to emerge and meet architectural requirements just in time for the team to be able to proceed.  They get to the point where they believe “agile architecture” is an oxymoron like “jumbo shrimp” or “deafening silence.”  It just doesn’t make sense to them.

The good news is there is finally starting to be some good information available about agile architecture.  The image on the left is one of many which can be found on the Internet when looking for information about this concept.  Finally, the agile community is putting some effort into answering the question which almost always arises during an agile transformation “What about the system architecture?”

First of all, teams need to change a lot of their thinking about architecture.  Instead of “how do all of these pieces and parts fit together nicely”, the thought process needs to revolve around minimizing the cost of change and delivering customer value.  So a good first step is thinking “how do I separate all of these pieces so change is easy” and following that up with “what value can be delivered with small pieces of the overall architecture in place?”  David Bernstein has an excellent post “Who Needs Architecture and Design?” on his blog.  In it he points out 6 major differences between agile projects and traditional projects when it comes to architecture and design:

1. Defer making decisions until they are needed
2. Constantly strive to provide value to the customer from day 1
3. Drive development from acceptance tests and unit tests
4. Use TDD to create “living specifications”
5. Seek to encapsulate as much as possible
6. Know what decisions cannot be easily encapsulated and therefore must be made up front.

It is interesting that all 6 of these items involve more than just an architect.  They involve developers and in some cases testers.  Everyone is involved in making sure the system functions properly as a whole, not just the architects!  All of this is covered in David’s Agile Architecture and Development – Essential Patterns and Practices course.  He is giving the course on June 16-17 in Seattle.  The early-bird discount expires on May 15.  This course WILL sell out, so be sure to sign up early at http://agilearchitecture-agileforall.eventbrite.com/.  Remember, this is a course for more than just architects.  Developers will get a tremendous amount out of this course – in fact, many developers say the course is a defining moment for them in their careers because they finally understand how to efficiently emerge code and designs to meet customer requirements rather than just coding to the requirement of the day.

The point of all this is to explain to everyone the concept of agile architecture is valid and not an oxymoron.  It requires different techniques and skills in order to be done properly.  You are not likely to just “fall into” doing it correctly.  I have done a bit of research on this topic and there are very few courses available to effectively teach these skills and techniques.  That is one of the reasons I recommend David’s course to my clients and now publicly on my blog.

Too many companies are starting down the agile path and ask the difficult question “What about the system architecture?”  The answer recently got a lot simpler: take David’s course and find out what to do and how to do it!  OK, if you can’t do that, then keep a few thoughts in mind and see how far you can get:

1. What can be encapsulated and decided later?
2. How can things be separated to reduce dependencies and the cost of change?
3. How can architecture and design decisions be driven by concentrating on delivering value?  In other words, don’t build architecture or design except as needed to deliver something with tangible value.
4. Which decisions truly need to be made up front in order to drastically reduce waste later?

Numbers 1 and 4 in the list really are two parts of the same thing in many cases.  If you can defer the decision you will likely have to encapsulate it.  If you can’t encapsulate it then you may have to pay a price later for deferring it.  This isn’t always true, but it sometimes helps to think of it this way.  However you think about it, you really need to concentrate on “just enough, just in time” or you will overbuild the architecture or design – which costs extra time and money (and in this economy both are in short supply!).  Number 3 is a key driver for success.  Don’t just build infrastructure, build it only in the context of delivering value.  The infrastructure will then emerge over time and have exactly the right amount to support the state of the delivered system.  Refactoring will be cheaper than overbuilding as long as the cost of change is kept low.  It seems like more work, but will actually be faster in the end!

Until next time I’ll be my clients will emerge their architecture and designs in agile ways in order to be Making Agile a Reality™ for their organizations.

Related posts:

1. Agile Architecture and Agile Testing – New Courses on the horizon Exciting news!  Some associates of mine are currently completing work on some...
2. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...