No, I don’t work in a company, and I usually work alone. So Scrum is not that relevant to me in practice. It’s just a topic I’m interested in (though in the past I worked once in a Scrum-like project and it was a very good experience).

Handling bugs in Scrum is going to be another post, but I’ll try and answer briefly here.

In Scrum a story is not done until it’s done, i.e. fully tested and working, and ready for release.

Which means when a developer marks a story as complete and ready for testing, the QA should test it asap. If a bug is identified the developer should fix it at their earliest convenient stopping point from the next story that they’ve moved onto, i.e. during the sprint.

If they can’t fix it during the sprint, because it’s too big or it’s identified too late in the sprint, it’s normally sorted at the start of the next sprint.

This obviously impacts the team’s velocity which can determine how much work they take on in the next sprint.

Depending on the severity of the bug and the time it takes to fix, this may have an impact on the release plan, which the client will not be happy about. But essentially it means that the team significantly under-estimated the story. Not much you can do about that – you either deliver late or throw more resources at the project.

This should be a very rare occurence in Scrum due the way you plan and estimate stories.

What’s your work situation Daniel? Are you self-employed or work in a company? How big is your team? Are you using Scrum or thinking about it?