1

We recently started implementing Agile in my current organisation We came across this interesting use-case.

I would like to understand what the group thinks of it and whether we are headed in the right direction.

1) The development team picks up stories, which will form the Sprint Goal, in the Sprint Planning Meetings. Which is assigned to members in Jira.

2) Developers start working on the sprint, and deliver features to QA for testing.

3) QA finds issues in what was given for testing.

Now our group seems to be divided as to whether these issues fall in the category of Bugs. Creation of bugs seems to be the source of conflict.

My personal opinion is that these are bugs and depending on the criticality we can decide if these need to be picked up as part of the current sprint work or not.

From my point of view a bug is traceable, while comments and test cases are not.

A bug also tells product that Stories may need to be more descriptive, and the product gets an idea about what it takes to get something done.

The team says that raising bugs, for current feature development and including them in the current sprint changes the scope in the burndown charts, which for some reason may be bad.

Just want to know what this group thinks about all this?

So there is no question about Creation of Bugs for issues reported from "Live", those bugs will continue to be created.

  • Possible duplicate of pm.stackexchange.com/questions/20526/… – Sarov Feb 23 '17 at 14:14
  • @Sarov The question seems like a duplicate, but it's slightly different. The referenced question is about defects found from a previous iteration, while this one is about defects found by QA within the current iteration. I think my answer regarding Released Defects vs. Incomplete Increments is probably applicable to the OP as well. – Todd A. Jacobs Feb 26 '17 at 20:58
  • The real X/Y problem here is that your organization is treating QA as an external process. QA and development need to work collaboratively, and then this whole issue will disappear. :) – Todd A. Jacobs Feb 26 '17 at 21:00
5

While you did not explicetly mention that you were doing Scrum you did indecate Sprint Planning. The guidance in the Professional Scrum Developer training, aimed at teams working on software, and derived from the Scrum Guide is that there are two sorts of bugs:

  • In Sprint Bugs - Any problem that is discovered during the Sprint on work that is part of the current Sprint is not a bug that needs tracked. We are still inside of the Sprint and the work is not deemed to be complete untill the Development Team calls the work as meeting your Definition of Done. This is just unfinished work, and warrants nothing more than a conversation between a coder and a tester. Maybe the coder and tester pair untill the issue is resolved, that would be most effective, or they need to add a few tasks so things dont get forgotten. How they agree to do that is an issue for the Development Team and no-one should be telling them how to do that.
  • Out of Sprint Bugs - Any problem that is identified in work that was previously marked as meeting the definition of done is considered an out-of-sprint bug. If the Development Team believe that the issue is small enough that it will not endanger their ability to meet their Sprint Goal then they should just fix it; Note it down and bring it up in the Sprint Retrospective so that The Scrum Team can figure out if their Definition of Done is sufficient. If however it will put the Sprint Goal in danger then it must be recorded and tracked as a bug. Do a root cause analysis and discuss at the Sprint Retrospective what you need to add to your Definition of Done to not have this sort of thing happen again.

The key parts to this are minimising documentation, bugs and root cause analysis, to only the times required. The Sprint Goal is the objective of the Development Team while maintaining quality with the Definition of Done. This provides the focus and transparency in the process that provides the Product Owner with working software, the Increment, at the end of the Sprint that meets their expectations.

Some Observations

We assign stories to developers in the Sprint Planning Meetings.

I would recommend against having Backlog Items assigned directly to Development Team members. Scrum (and Agile) works because we move from individual accountability to group, or team, accountability. This fosters self-organisation, and every time you hold an individual accountable for a piece of work you stop self-organisation dead in it's tracks.

Assign Backlog Items instead to the Product Owner, it is they who are accountable for the Backlog and everyone's understanding of it.

Developers start working on the sprint, and deliver features to QA for testing

This statement concerns me as it implies that you have either a separate QA Testing team or sub-teams inside of your Development Team. Since we can't have working software unless it is tested, test needs to be completed as part of the Development Team. Separate QA is waste if you have a professional Development Team that produces working software. It sounds like an organisational imposed condition is preventing you removing this impediment. This demonstrates a lack of commitment from management to your agile transformation as this is a fundamental, we'll understood and documented, issue that is a common starting point. Maybe they just have not made that change yet, but untill it does you will be unlikely to get the quality of software you should. You will also continue to incur significant rework.

QA finds issues in what was given for testing

The Development Team is accountable for creating done increments of working software. If QA find any issues then this is a serious breach of trust and I would hold the Development Team to account. If you are just starting down your road to agility then raise this issue at the Sprint Retrospective and brainstorm solutions.

If your quality is high enough then QA will no longer be able to justify their existence. They are product of poor software quality, and are not a feature of your future.

Now our group seems to be divided as to whether these issues fall in the category of Bugs. Creation of bugs seems to be the source of conflict. My personal opinion is that these are bugs and depending on the criticality we can decide if these need to be picked up as part of the current sprint work or not.

Your personal opinion does not matter, the Development Team own this process and are the only one's that decide how the work is done. Hold them accountable for done increments of working software, stand back, and let them get on with it.

From my point of view a bug is traceable, while comments and test cases are not

Proper tooling can aliviate that. In most tracking systems, i use VSTS, comments and Test Cases are just as auditable as Backlog Items.

A bug also tells product that Stories may need to be more descriptive, and the product gets an idea about what it takes to get something done.

The opposite is true, only the lack of bugs tells the Development Team what it takes to get things done. The rest is Undone work which erodes trust with both Product Management and customers. You need a tighter Definition of Done.

The team says that raising bugs, for current feature development and including them in the current sprint changes the scope in the burndown charts, which for some reason may be bad.

If it's small, then just fix it. If it's big then it needs to go onto the Backlog and be ordered by the Product Owner. This is the only way the Product Owner can understand the u done work that is in the product.

So there is no question about Creation of Bugs for issues reported from "Live", those bugs will continue to be created.

These are very out-of-sprint bugs and I hope the full list of them, along with their root case, is assessed at the Sprint Retrospective and the Definition of Done enhanced accordingly.

  • 1
    When I said we assign work to the dev team. I meant that we just assign it to them in Jira. Its actually the team as a whole that decides what should be picked up as part of a current sprint. :) . Thanks for taking out the time your post is an interesting read. – ichthyocentaurs Feb 23 '17 at 10:16
  • What do you mean by "assign it to them in Jira"? Does it have an individual team members name? – MrHinsh - Martin Hinshelwood Feb 23 '17 at 11:03
  • @MrHinsch - he def means that the team pull in the work but then they put a specific developer on the individual story in Jira rather than leaving them unassigned and letting a developer pick up the task. – Venture2099 Feb 23 '17 at 12:13
  • I agree with most of your answer, except for Separate QA is waste if you have a professional Development Team that produces working software. and If your quality is high enough then QA will no longer be able to justify their existence. In regulated environments, there is often a mandated need for independent QA. Even outside of regulated environments, there are advantages to having an independent QA team, if you are willing to incur the additional time and cost associated with it. – Thomas Owens Feb 23 '17 at 15:40
  • 1
    @venture2099, unasigned is much better than assigned to a team member. Assign to the PO would be best. – MrHinsh - Martin Hinshelwood Feb 23 '17 at 16:53
1

The team could experiment with different ways of handling defects during an iteration, after some experiments they can pick the one they liked the most. There is not one good way, this differs per team, company and industry.

Keep the experiments small, focus on the problem. If to many bugs slip from development to the manual testing phase you could experiment with more test automation or pair-testing during development. Formalizing defect registration is the last thing that comes to mind as being effective.

Let the team come-up with experiments they could try to improve quality during a retrospective. The team should include developers and qa.

  • 1
    When I said we assign work to the dev team. I meant that we just assign it to them in Jira. Its actually the team as a whole that decides what should be picked up as part of a current sprint. :) – ichthyocentaurs Feb 23 '17 at 10:16
  • 1
    Good! :) I will remove my section about this then :) – Niels van Reijmersdal Feb 23 '17 at 10:50
0

Sounds like in the case you're talking about, the story should be rejected, and recycled through the development process. Having a story rejected should leave a trace - in the comments for the story, and probably the sprint-tracking graphs (look for a story state change graph or rejections graph - burndown isn't the only graph available to you, especially if you're monitoring particular pain points).

Pre-retrospective, it's good for the scrum-master to go through the cards for the sprint, ensuring they're up-to-date and looking at what comments and tasks they've accrued over the sprint.

If the code written for the story doesn't fulfil the requirements (or doesn't work!), it isn't a completed story. The card should retain its priority. There are odd corner cases where the issue might be farmed off to another card, but this would be an exception. If the card does get signed off with the fault, you're delivering defective code... which is what the process is aiming to avoid!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.