My Agile Team: More Code, More Problems

Interesting. I have a couple of comments based on the exact same experience.

First, don't get trapped in the "two backlogs" situation, where you're maintaining/prioritizing a defect list along with a backlog of desired business functionality. Use one list. Define the capacity for your sprint. Work with the product owner to fill that bucket of time with work. If the product owner decides to fill your sprint with defects, they're choosing quality over functionality. If they fill it with new features, they're choosing functionality over quality. Simple as that.

You should always estimate the work you're bringing into a sprint. Without estimates you have no way to guage the work against your capacity. More importantly though is that you cannot commit to a set of work for a sprint unless you have a reasonable expectation that it can be completed.

The problem of course comes in between planning meetings when new critical things come up.

Plan and plan often. Reprioritize your sprint backlog if necessary. There's nothing to say you can't meet as a team and discuss bringing higher priority work into the sprint. It's not ideal and you're modifying what you committed to at the beginning of the sprint, but you shouldn't be afrraid to either. If the PO, Management, or the business is pushing you to bring more work into your sprint, welcome the change -- just ask them what they're willing to give up for it. If it's a 20 hour task you're bring in (here's why you need estimates) then tell them to take 20 hours worth of existing work out of the sprint.

Since to our Product Owner everything that's critical needs to be fixed now, there's not much we can do to re-prioritize.

I'm reading this to mean that your PO is prioritizing all defects as "critical" just so they get fixed? Is that correct? If so, the prioritization of defects should be a collaborative effort involving the team and the product owner. All sides should be involved to prevent unreasonable things like this form happening.

If the PO still insists on everything being the same priotity then tell him that for sprint planning, instead of having a meeting you're just going to let the janitor pick the work for the sprint. If it's all the same priority, it shouldn't matter right? Hopefully they get the idea.

Our manager took our extremely rough time estimates and told the company that meant we would be done with everything in 2 months so we're all shooting for that goal.

This comment is worrisome. Why is a manager talking to the business? The team should be interacting with the product owner, through the ScrumMaster if necessary, but ideally directly. Go back and tell the business that your team is producing all the artficts necessary for them to gauge your progress and when you will be done. Tell them to look at the burndown charts and your velocity. That's where it should come from, not a manager.

Firstly, I agree with previous poster about the importance of having a prioritized backlog (no duplicate priorities) - otherwise your team can't commit.

I would also like to comment regarding the quality aspect. In our team we have removed the PO and management from dealing with quality. As long as we show good progress we are trusted with judging the quality aspect of the software within the team. After all, it's we who are the software engineers. This means that we reduce the parameters the PO has to play with; from three (time, scope, quality) to time and scope. And time is pretty much defined as "in a sustainable pace" according to scrum.

We started the no-negotiate policy regarding quality just after last summer. We then had to work two sprints only focused on bugs. The goal was and is zero bugs at all times. - No backlog items were finished. We now always fix bugs continously as they appear. By doing this our PO only has to worry about prioritizing and coming up with backlog items, not quality or bugs/tradeoffs.

Working in this way promotes quality, makes it non-negotiable and already estimated for when sprint-planning takes place. (The velocity is the velocity, and as far as we know - there will be as many bugs as last sprint.)

Henrik Johansson