How We Actually do it: Accounting for Bugs in an Agile World

Today I’d like to share with you a really important aspect of Agile software development – how to account for bugs in your daily plans.

I am frequently asked by teams I consult with how to deal with bugs if you’re Agile and using Scrum. Questions like the following come up time and time again:

“Should I track hours burned fixing bugs?”
“Should the hours burned on fixing bugs count toward my Story Point velocity?”
“When do you schedule bugs and should this be done during Sprint planning?”

You Need to Account For Bugs

My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we’re considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don’t, you will have an inaccurate measure of your teams productivity – something that will definitely lead to poor planning and late deliveries. (….read more)

Time to fix bugs therefore, should come out of your teams available capacity. So when one schedules bugs to be fixed, bugs should be estimated just like you do with tasks on the sprint backlog. Developers must therefore determine for each bug scheduled, the hours remaining to complete the bug daily. And this WILL be reflected in the daily burn-down along with tasks.

Calculating the Teams Capacity

Essentially teams have a certain capacity i.e. available time during the week to do meaningful work. This can be calculated as follows:

(# of team members) * (# days in the week) * (hours in the day) = capacity

You should however modify the capacity to reflect reality (time spent in meetings, doing email, vacation etc) so this can get quite complicated. The best thing to do is to figure out what percentage of time per day you get real work out of the team on AVERAGE.

At our company we work on a 4 or 5 hour day therefore:

Actual Capacity = Capacity * 0.5

Once again, don’t get hung up on being extremely accurate as this all averages out in the end. Just be reasonable in your approach. If you want to take vacation into account etc one can get quite fancy about this, but usually a rough estimate works fine. It does for my team.

Resolving Bugs Shouldn’t Count Toward Your Story Point Velocity

The time spent resolving bugs however should NOT be counted towards the Teams overall Story point velocity. i.e. I’m not going to give my team credit for buddy code!

Bugs should be scheduled into a sprint or iteration along with user stories during the Sprint planning meeting. So the total time to implement tasks and fix bugs should not be more than the available capacity you determined for the Team (See above capacity calculation). Note that this total time in hours is the intersection with the Y-axis on your burndown.

I know many coaches will argue that bugs should be tracked seperately and that bugs should be dealt with in the sprint that they’re found. However in practice this is not always practical. Try it, and you’ll improve your teams predictability significantly.

Next week I will give a detailed account of how we do Planning.

If you have any questions about Planning or Bug Tracking in general or if you have strong opinions on this topic, please don’t hesitate to pitch in!

My Agile Team: On Time Estimates

Picture courtesy of John-Morgan on flickr

Welcome to the second installment of my new series, My Agile Team, where we’re following my team’s progress in getting more Agile and in moving from one project to multiple projects. Right now, we’re still trying to put out fires and finish up the big project. We hope to start adding in things from our other projects in a couple more sprints.

The fires I mentioned are our term for the emergency stuff that pops up and has to be taken care of Now. This is usually things that customers will see; their bill being the most important. These seem to still pop up every couple of days so we have to drop our Sprint tasks and take care of them quick, fast, and in a hurry as my Dad says. It looks like we’ve probably stomped out the bulk of the underlying problems causing the most important fires so this coming week I’m hoping will be a little less crazy (of course now that I’ve said that, we’re in trouble). Once we all have some distance on these issues my goal is to do a deep retrospective just on these issues that have come up since Go Live and see if we can root out anything we should have differently for next time.

One thing I’m struggling with right now is trying to get the Higher Ups to understand why we shouldn’t use real time estimates on the stuff left on the big project. Read on for my thinking on this and how I’m trying to influence things.

One of the big problems I talked about in the My First Agile Project series was lack of management buy-in on our project. They all knew we were doing Scrum and supported our efforts, but I don’t think the real nuts-and-bolts of the process sunk in.

One of the places I’m sure we didn’t do enough education is on putting estimates on tasks. Our manager wasn’t a part of the Scrum team during the big project so she doesn’t really know what we used to do. Now that we’re trying to finish up, she wants real time estimates on tasks to tell others in the company when we’ll be done. I appreciate the idea behind this, but I’m not sure about the best way to give her and the company what they’re asking for. I gave her my copy of Mike Cohn’s Agile Estimating and Planning with some relevant chapters picked out but that’s obviously not going to be enough on its own.

Obviously part of the point is that we don’t know how long these last things will take. All we can do is put rough “ideal time” estimates on them but then as Cohn notes in the book, you run the risk of people not differentiating between “ideal time” and “real time”. Since we really have very little in the way of big items left on the backlog, our compromise for now is putting ideal estimates on with the understanding that there are fires to be put out that seriously affect those times. Then we have to hope that this understanding gets communicated up from our manager to those higher in the chain. This isn’t optimal but I’m hoping once we’re a couple more sprints out and putting in other project tasks into the backlog that we can come to a better understanding on estimates and communicate that across management.

This is a tricky time for our team. On the one hand, we launched the product finally and people like it. On the other hand, we were very late and we’re still putting out fires. Our official manager is now back to officially managing us and hadn’t really had a lot of immersion in the Scrum process during the project. So we have to educate her, get back some lost credibility due to the lateness of the project, get back on track with Scrum, and finish up the last issues. We had a joke in the department that Only 3 Things Can Be Top Priority but we’ve recently increased that to 10 as having 3 Top Priority things is now seen as kind of a luxury. I fear if we don’t get our act together on multiple fronts all at once, the company could really start to see the Scrum/Agile process as a failure and we could go back to our old ad-hoc, somewhat random task assignment process which none of us wants.

My biggest piece of advice for trying to turn your team into an Agile team is to get on the same page as a team and educate the heck out of everyone. Each other, managers, everybody. Have your books, articles, presentations in order and bring them out at every opportunity. If you have to give in on a piece of the Agile process, make sure everybody knows what the tradeoffs will be. Speak up. If the process is important to your team, it’s important enough to speak up about, even to management.

Well, that’s it for this installment of My Agile Team. I’ll be back next time with what I’m seriously hoping will be the last sprints of cleaning up the big project and putting out fires. Thanks for reading and as always, if you have advice or comments please make them below. I love hearing from everybody and obviously, I need the help. 🙂

Previously in My Agile Team
My Agile Team: On The (Scrum) Road Again

Top 10 Activities of the Product Owner

Over the course of the past 5 years, I have often been asked about the role the Product Owner plays in an Agile company. More recently in a rather controversial blog post by Adam Bullied he raised the question – Is there such a thing as an Agile Product Manager?

From my experience, there is. And this role in Scrum is defined as the Product Owner. The Product Owner from my experience differs from that of the traditional Product Manager role in many ways. Additionally, the role the Agile PM plays may vary depending on the environment and situation at hand, but for certain there are key activities the Agile PM must perform.

The Product owner (or Agile PM) shoulders all the responsibility for Project success and is ultimately responsible to the Team, stakeholders and to the company. With so much at stake it’s easy to get bogged down or revert back to old ways and the whole team suffers as a result. In order for Scrum to work the Product owner has to focus his time on activities that matter. (read more…)

Here are the top ten activities I have experienced a Product Owner must perform well in order to keep scrum teams effective:

1. Creates and MAINTAINS the Product Backlog. I emphasize MAINTAINS as this is an on-going job and more than likely a full-time activity. Nothing is constant in the world of software and it’s important that the Product Owner keeps his/her eye on the ball. Note: the Product Backlog must be groomed prior to the Sprint Planning Meeting in order for the team to remain productive.

2. Prioritizes and sequences the Backlog according to business value or ROI (there are lots of tools to help Product Owners do this and lots of books on the subject) The Product Owner is required to have the Backlog sequenced prior to the Sprint Planning Meeting. This means that each user story must be ordered by relative importance. It’s no good to have 5 high priority or 5 medium priorities. It’s important to know which User story is #1, which is #2 etc.

3. Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint. User Stories are elaborated at the last responsible moment and it is the Product Owners responsibility to be there during the Sprint Planning meeting to help the teams to understand exactly what is required.

4. Conveys the Vision and Goals at the beginning of every Release and Sprint. The Product Owner must continuously remind the Team of the Sprint and Release goals. This helps to keep the team on track and serves as an over-arching yardstick for the team to measure their activity and progress against.

5. Represents the customer, interfaces and engages the customer. The Product Owner must continuously engage the customer and stakeholders to ensure the Team is building the right product and therefore delivering the ROI expected of it. The Product Owner has the opportunity to steer the team in a different direction at the end of every Sprint, so he/she must be ready to do just that if necessary.

6. Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives. There’s always a lot going on and always an excuse to miss the meetings. But each of these Scrum ceremonies is another chance for the Product Owner to inspect and adapt. And as a result being present at these ceremonies is tantamount to success.

7. Inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done. Work that is either not complete or un-done needs to be re-prioritized or sequenced. An Agile PM is one who is quick to recognize and understand change and to ensure the Product Team adapts to the change in landscape, be it competition, target market or other.

8. Can change the course of the project at the end of every Sprint (30 days if you’re following traditional Scrum methodology by the book). The Product Owner is in complete control and can steer the team in a completely different direction at Sprint boundaries. And good Agile teams will welcome this change as long as the Product Owner is confident and knowledgeable.

9. Communicates status externally. The product owner is the voice of the Team to the outside world and should ensure that all channels of communications are open and that projects have the right amount of support required to succeed.

10. Terminates a Sprint if it is determined that a drastic change in direction is required e.g. a competitor releases a new version which demands a counter response. This is a pretty serious event for Scrum teams. And what this means “technically” is that all work done up until that point is lost. I have not seen this done to many times in my career especially since, there’s really not that much time between Sprints in any event.

The responsibilities of the Product Owner are onerous and there is no one else on the team to cover for him/her or pick up the slack. So if you’re choosing a Product Owner, choose wisely, the difference can be success or failure for the entire project or, in the worst of circumstances, the success or failure of the company.

Your Unit Tests Lie to You

Photo (c) Janusz Gorycki

Achtung: A Bunch of Obvious Statements Below

Continuing the grand tradition of writing “controversial” posts, let’s take a look at unit tests – which for some folks seem to be the new gospel, the best thing since sliced bread, the cure to all our ailing.

Well – the truth is that, in the agile community unit tests seem to be a little bit overrated. Or, to be more precise – they are often incorrectly used as a “silver bullet” substitute for the tedious, labor-intensive, time-consuming, boring and un-gratifying, manual integration and system tests. They quite often, and wrongly, become the one and only QA process in the project. Let me tell you – these hope of getting rid of integration and system testing are false and maintaining them is extremely dangerous.

The Purpose of Unit Testing

Unit tests are a good tool for two purposes:

  • they are a fast and simple verification vehicle, allowing you to test your unit’s responses to variety of external stimuli – either ones that you could think of while developing, or ones simulating conditions that led to a bug in your code (if these conditions can be reduced to a unit test, which may or may not be the case)
  • they give you a cerating assurance that the code you have created for the unit will not be so easily broken in the future by somebody who is refactoring it for whatever reason (bug fixes, improvements, rearchitecting, whatever)

And that is pretty much it.

All other valid reasons for unit testing can eventually be reduced to these two. I remain in a violent disagreement with some of the other “qualities of unit testing” listed in the linked blog post of my esteemed colleague. I won’t attempt to go over them one by one here though, for the lack of space.

Don’t get me wrong – unit tests are extremely useful – these days they are quite essential. Applying unit test to your code will make it better. You should absolutely be unit testing your code, whenever possible. You should be trying whenever possible to create unit tests mimicking conditions that led to reported bugs. But – it is a criminal offense to stop there. And it is an even bigger crime to insinuate that unit testing alone is a sufficient QA process for any sort of serious software project.

Ok, So How do They “Lie”?

Let’s try to answer the question of what purposes unit test are not useful for, or what are the dangers of relying on them, shall we?

  • Unit test are not a necessarily a means for documenting your system, sorry. I have seen a fair amount of unit test that did, and an even larger pile of those that didn’t, instead increasing chaos and miscommunication. Tests will only become your system’s docs, if you create them with this specific purpose in mind. The same can be said about your actual code – it may or may not be self-documenting
  • “Green” (all passing) unit tests don’t necessarily mean that your system is healthy. It is not humanly possible to test for every scenario, you can break your system in many funky ways and still make your even most stringent unit tests pass. Boy, do I have stories to tell about that one…
  • Trusting your unit test mocks is wrong. Mocks are only able to superficially mimick the real world. Claiming that mocks can substitute the real environment is like claiming that a blowup doll is a good approximation of a marriage
  • They are worthless if they are slow. In a non-trivially large system, unit testing can take hours (if not more) – and your automated build will take the same amount of time. This makes unit tests worthless as a vehicle for instant feedback – nobody will bother waiting half a day for the results of a build after they committed some refactored code. Yes, you can and should partition your code to smaller modules, but then your builds do not test everything – they only test your module

All of the above are valid problems (and I challenge you to prove me wrong), but the next one is the kicker:

Even if you are a master programmer, you have no idea what to test for. There, I said it. And I have a war story to back me up:

One of the best developers in our team has created a fine piece of code, unit tested the hell out of it and was proud as a baby of his accomplishment. And a fine piece it was indeed – chapeau bas! Yet – it failed “in the field”. Its problem was performance – it failed to be efficient in the face of real-life conditions. And the developer in question could’t quite believe his eyes whan somebody else on the team investigated the problemand pointed out where exactly in his code the root cause of the problem was – it was a classical case of “this one is obviosly correct, it is not necessary to test it”. So if this bloke is unable to create proper unit test suite (and his software development skillz are absolutely top-notch), nobody can.

So please, don’t fire your QA department just yet. Their job is still important, even if you unit test.

Janusz Marcin Gorycki

Janusz is a software developer and team manager with over 15 years of experience. He has been working for a long time for multi-national corporations, mainly in the telecommunication and embedded systems industries, He is now a co-owner of SPARTEZ – an independent agile consulting and software development company

Why do we have a Product Owner anway?

I can’t stress enough just how important the role of the Product Owner really is. This job is not for the faint-of-heart. In fact, the Product Owner is probably the most important individual on the Scrum team since he single-handedly is responsible for driving the direction the team is taking.

The Product Owner And The Team

The team is responsible for how they are going to implement the functionality. The Product Owner, on the other hand, is responsible for WHAT they are going to build and in what priority order. Although, there are times that Architectural elements will be prioritized ahead of business functionality, for obvious reasons. So, the Product Owner is like the driver on a bus. He can drive the team around in circles, off a cliff or he can ensure the team is taken to a place where it can make a significant impact – Imagine that!

Who Should Be A Product Owner

The activities that Product Owners are responsible for, require competent individuals who are passionate about what they’re doing, are well informed, have excellent domain expertise and are customer and ROI focused. Scrum is all about producing company value or ROI, so it is critical that the team is ruthlessly focused on THE most important tasks and should be based on over-arching business goals. Remember that more than 60% of all features are never used. As a result, Product Owners have to make sure that they’re not wasting valuable resources (the most significant company cost is people cost) on functionality that is not really required.

The Product Owner And Scrum

The beauty about the Scrum process is that it provides a framework that pressurizes (forces) the Product Owner to sequence work. I use “sequence” purposefully as opposed to “prioritize” as there may be multiple high priority features to work on and the Product Owner must choose which, based on the teams available capacity at the time. This is hard work and careful thought has to be put into this activity. In many cases, the company’s survival depends on the positive influence a Product Owner has over the team. Since Scrum is such a transparent process, you’ll know very quickly if the Product Owner is doing his/her job well.

So choose your Product Owner wisely – a good Product Owner is worth his/her weight in gold!

In the next blog we’ll cover the specific activities a Product Owner is responsible for.

Welcome Jack

Dear readers

We just got a new writer for His name is Jack Milunsky.

As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. Jack also writes to his own blog – check it out.

Please, welcome Jack and comment on his writing.

Best regards,

By the way, if you are thinking about becoming a permanent contributor to author, contact me directly.

Jack Milunsky

As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. You can follow Jack for great tips on Agile at

My Agile Team: On The (Scrum) Road Again

Picture courtesy of qmnonic on flickr

Hello and welcome to the start of my new series called My Agile Team here on This series is a sequel of sorts to the My First Agile Project series. From here on out, the plan for this bunch of articles is to follow my team as we move from being on one big project where we (mostly) used Scrum to being on multiple projects where we will (hopefully) really use Scrum. We all intend to learn from our mistakes the first time around and to adhere more closely to the recommendations that make Scrum work so well. But, as everyone knows, when the rubber hits the road even the best of intentions can go by the wayside, accidentally or intentionally.

In this first post in My Agile Team, I’ll talk a little bit about the team’s plans and what happened during the first 2 weeks of our transition. In our last project, Scrum was brought to us by the vendor and our management signed on fairly enthusiastically. This time though, we’re on our own to implement and stick to the plan, at the same time moving from a big project we all worked on to multiple maintenance projects. We know what we want to do, but will that turn out to be what management wants to do? Will we even be able to make the transition successfully? Keep reading to find out!

As I said, we’re coming off everybody being on one big project for the past 18 months or so. A lot of the team came to the company during that project so that’s all they know. Now that we’re live with that project, we’re moving to working on all the things that were neglected during the past 18 months. This includes maintenance on a few different bigger internal applications as well as building some new things for various departments in the company. Since we all like Scrum and want to keep going with it, we need to figure out how to incorporate these multiple projects into our Sprints.

Right now, we’re still doing cleanup on the last remaining items from the big project. We’re doing 1 week sprints in order to get things out quickly but I’m not sure this is the best idea. If you’re on a Scrum team doing 1 week sprints, please talk about your experience in the comments as I would love to hear about how you structure things so that you can get enough work done. The server admin part of our IT department has Wednesday evenings set aside for production deployments so we’re working around that. We have to have everything that needs to go into production done and tested before Wednesday evening. In practice this means it has to be ready by Tuesday at the latest so the testers can get their hands on it. Then we do planning on Thursday. The best thing about 1 week sprints is that our planning meetings don’t exceed 30 or 45 minutes. During our old 4 week sprints we would struggle to get all of our planning done in a full day. Because of the Wed. deadlines, we only end up getting a couple of days worth of actual work in so after another couple of weeks we’re going to 2 week sprints. This will give us much more breathing room while not blowing up our planning meetings. Once we start putting other projects in the mix, we’ll see how short we can keep our meetings.

Luckily, our management hasn’t been super strict about the production procedures since we just recently we live. We’ve pushed emergency/important fixes on days other than Wed. without problems, although it’s frowned on. We’ve also been allowed to do our own pushes to production without the deployment paperwork (it’s in Jira, our bug tracking system, but I think of it as paperwork) we normally have to go through. Since we’re an insurance company, we have to adhere to pretty significant regulation and auditing procedures. These relaxations won’t last long though so we’ll be on standard operating procedure pretty soon.

In addition to our sprint tasks, we’ve been taking care of the normal daily fires that pop up with new production software. Even with this added load, we’ve been pretty good about finishing our tasks. It’s very nice to have a list of things to work on rather than just scrambling around trying to get everything done.

So far, so good is my review of the last 2 weeks. It’s been crazy but good. We haven’t had any major problems with anything we wrote and we’re taking care of everything at a quick clip. Next time in My Agile Team we’ll probably be done with our last cleanups on the big project and finish up the 1 week sprints as well. Stay tuned and hear how it went! Thanks for listening and if you have advice for us in making this transition, please post in the comments. We need it! 🙂

Everybody Needs … Unit Tests

Picture courtesy of Lotus72@flickr

… please remember people, no matter who you are, and whatever you do to live, thrive and survive, there are still some things that make us all the same: you, me, him, them – everybody, everybody! – this is a fragment of Blues Brothers’ “Everybody Need Somebody” song. Nothing to do with software development but when you change the next line of this song from “Everybody needs somebody” to “Everybody needs Unit Tests” it becomes closer to software development.

I intentionally used lyrics of this song to keep everyone’s attention (just a little bit) to this post. If you are familiar with TDD and unit test your code you can disregard it – I’d like to address this post to all software engineers/developers/programmers/etc. that DO NOT unit test their code.

In this post I will try (again) to convince all software developers that still don’t unit test their code that it’s right thing to do and it’s damn simple.

Assume that Agile software development is wrong, really wrong

You don’t have to be the fan of Agile movement – you can even think it’s stupid, immature and doesn’t help software development at all. Maybe you’re right, maybe not – it’s rather a question of taste. You don’t have to use or like Scrum, you may think that XP is crazy and an overkill – you have right to think so. I can understand everything but PLEASE do unit test your code! Forget about Agile, forget about processes and methodologies – just unit test your code.

I just took over another project that is quite complex (of course it is!) but has NO SINGLE unit test (or any test at all). More so, there is no documentation of any kind. Yes I can read the code and see what it does – that’s simple but how the hell I could know it does what it should do? How could I know it’s not a mistake made by the developer who created this creature?

This code lacks Unit Test, but fortunately day after day I add more and more and I’m more confident this piece of software works.

Unit Testing once again

If you want to know something more about unit testing check out our previous articles. I will just recapitulate the most important, in my opinion, qualities of unit testing:

  • unit tests document internal and external architecture of the software system
  • unit tests help you and other developers to immediately see whether code “improvements” broke already existing code
  • unit tests help making your software bug-free – all issues should be addressed by writing a failing test first
  • unit tests together with code coverage tools improve quality of your software
  • unit tests can be used as a presentation platform – you can present hard to visualise issues using unit testing green bar – green means that it works
  • unit tests significantly improve team confidency in progress – if all the tests pass it means that all features implemented so far work and nobody broke the system
  • unit tests improve efficiency – you don’t have to perform laborious manual tests again and again after code changes, just start unit tests and watch the red/green bar
  • already there but so important that worth reminding – unit tests work as a DOCUMENTATION (auxiliary or main one)
  • I’m open for your propositions

I hope I convinced you to start writing unit tests – if you don’t like or believe in Agile movement it’s OK. Unit Testing is just an obligatory practice of every decent software developer. If you do unit test it doesn’t mean you’re good one but if you don’t unit test you’re a poor developer (I mean it).

I wonder when unit testing will be taught obligatory at every decent university. It does so many good and is so simple – people, please – write unit tests!

If you have any ideas how to convince every developer that unit testing is right thing to do I’m open for suggestions.