Search Sort Posts:  Oldest to newest Newest to oldest

10-27-2008, 10:07 deeg Joined on 09-11-2008 Posts 3 Bugs as a Product Backlog item seems awkward Shouldn't bugs be associated with the original user story? Why is there the redundancy of creating a bug and then immediately creating a task to "fix the bug"? Shouldn't it be inherently understood once the bug is created that is should then be fixed? I really like this process template and the task board application; however, this is the biggest deficiency I have noticed so far.    Report

10-28-2008, 9:42 Crispin Parker Joined on 11-13-2007 Posts 951 Re: Bugs as a Product Backlog item seems awkward Hi Deeg, Thanks for the feedback. Have you watched my "Bugs and Defects" task board web cast? It explaines how we intended treatment of bugs and defects to be handlled in the template. It might shed some light on the template model. http://www.scrumforteamsystem.com/WebCasts/TaskBoardGuides/Guide005.html Regards, Crispin Parker, Technical Consultant, Conchango. "It is better to light a candle than to curse the darkness"    Report

10-28-2008, 2:25 deeg Joined on 09-11-2008 Posts 3 Re: Bugs as a Product Backlog item seems awkward Thank you for the reply. Yes, I've watched the web cast. Actually, this is what alerted us to the problem we will have with managing our bugs using the template. During the web cast, it is mentioned - "tester would go talk to the developer about the defect" - In terms of accountability, we feel this should be logged as a work item (as opposed to a conversation with the developer); also, there could be multiple defects associated with a task - checkins should be applied separately for each one. The web cast also gives the example of creating a bug and then redundantly creating a task in order to assign the bug. I don't envision a situation where more than one task would be related to a bug and would rather just assign a developer to the bug directly. Also, I would want a potential relationship between the bugs and user stories. I could envision explaining that a user story was not yet completed because it had x bugs that need to be fixed before calling it complete. Our bug/task ratio tends to favor bugs - in other words, we usually have far more bugs than tasks - we would rather not see these mixed in the product backlog. Some case studies to demonstrate how the current process template is used when it comes to bugs/tasks and PBI's may be helpful.    Report

12-01-2008, 3:47 Haemoglobin Joined on 12-01-2008 Posts 5 Re: Bugs as a Product Backlog item seems awkward Agree with everything you said mate - was the first thing I thought when I saw the video without even trying it out... is a shame because everything else was looking really good apart from that? Immediate questions were "how do I associate a bug to a story" and "how can I record defects in the system without using verbal communication alone" Of course you could probably just re-use the description field for these, however I'm sure there are better ways.     Report

12-02-2008, 2:50 DancesWithBamboo Joined on 12-16-2007 Posts 9 Re: Bugs as a Product Backlog item seems awkward I think you might have some smells here. 1) You don't think a conversation between 2 commited people results in accountability? 2) "Favors bugs", why on earth do you have more bugs than tasks?  3) "Assign the bug", tasks are not assigned in scrum, they are signed up for. 4) "Story not yet completed because it had x bugs", unfinished in-sprint defects are not bugs.  This might be where you are having trouble with the template. See http://scrumforteamsystem.com/cs/forums/3337/ShowPost.aspx for some previous discusssion on bugs and scrum. Cheers    Report

12-02-2008, 2:59 deeg Joined on 09-11-2008 Posts 3 Re: Bugs as a Product Backlog item seems awkward 1) Why risk it. This is a main benefit and purpose of TFS. 2) Industry average experience is about 1–25 errors per 1000 lines of code. Even a ratio of 2:1 bugs vs tasks would produce quite a few bug work items in a moderately sized project. 3) Okay, then how can I assign myself to the bug work item if I sign up for it. 4) See #1 where the conversations don't always cut it. There should be a visual representation of what is remaining. I'm still interested to know the benefit of the redundancy between creating the bug (PBI) and task (SBI) as demonstrated in the video.    Report

12-02-2008, 11:28 Haemoglobin Joined on 12-01-2008 Posts 5 Re: Bugs as a Product Backlog item seems awkward Maybe there would be uses for that redundancy (sometimes) - where the PBI "bug" is described by the tester in user speak, and the task to be done to fix the bug is described in a technical way by a dev once the bug has had some initial investigation? Historically using standard TFS - our testers have been recording the failures in the main description area of the work item (which isn't the best but works ok) + file attachments for screenshots etc - along with conversations for clarification. I'm imagining that using the Scrum for TFS plugin we would continue recording in-sprint defects in a similar sort of way.    Report

12-03-2008, 5:24 DancesWithBamboo Joined on 12-16-2007 Posts 9 Re: Bugs as a Product Backlog item seems awkward I have to argue with you on  #1.  TFS is actually designed for product planning and integrating developers into that process.  It is actually terrible at bug tracking.  If I wanted to record as many bugs as you want to, I would consider Mercury QualityCenter or FogBugz or some other tool designed for the purpose. The reason bugs are at the PBI level is that the word bug in the context of scrum is intended to only be used where there is a defect found in production code.  In this case the defect needs to be prioritized by the PO against all of the other features and scheduled into a future sprint.  Many bugs may go unfixed because new functionality results in more business value than fixing them does. I am making an assumption based on what you have said that you are not the PO.  I will emphasize that you do not want to put in-sprint defects in the conchango "bug" template at all because this exposes that huge laundry list of crap that your team is generating to the PO.  The Backlog is his to manage and bugs are also a part of it; but work not done correctly or completely is a team problem and should be recorded as necessary at the SBI level.   I'm not sure whether your defects are actually bad code or missing functionality.  If it is the later then I would recommend adding more SBI's to the PBI as the new work is found.  If too much of this is found later on in the sprint then that might be a sign that not enough work was done on the story and conditions of acceptance.  I find a lot of stuff like this ends up back up at the PBI level for prioritization by the PO because it isnt part of the original story.    If you really do have bad code generating all of these defects then you need some more engineering practices; not more tracking.  More unit testing, peer review, pair programming, etc. Anyway, that is why bugs are at the PBI level.  They are there for the PO to see and prioritize along with the rest of his stories.  There is no redundancy because the bug is a story that has a business value and priority.  It is written from a business prospective.  SBI's are then used by the team for task planning during a sprint.  There are different audiences with different needs for the bug PBI and it's attached SBI(s). Cheers    Report

12-03-2008, 11:49 Haemoglobin Joined on 12-01-2008 Posts 5 Re: Bugs as a Product Backlog item seems awkward Thanks Bamboo I am seeing where you are coming from (the different audiences discussion). Have you done projects with a test team and if so, curious how they communicated defects back to the team in-sprint? In our case, the test team would not be interested in the SBI's (developer tasks), but the PBI alone which is the whole story described from a user perspective. If they find defects - do you think that it is reasonable that they are recorded *within* the PBI either as an attached file or simply in an area of the PBI description text? Now I'm not saying verbal communication won't take place - but something needs to be recorded for the sole fact that people's memories are *bad*. I for one, if I was a tester would forget what the defects were by the time I went to the developer, or as a developer by the time I go to fixing the defects I would have forgot what the tester told me. As an interesting aside - have a look at the bottom of this page: http://www.codeplex.com/scrumdashboard/Wiki/View.aspx?title=Installation%20instructions&referringTitle=Home It seems related to this discussion but I do not fully understand what they are saying..    Report

12-04-2008, 1:56 DancesWithBamboo Joined on 12-16-2007 Posts 9 Re: Bugs as a Product Backlog item seems awkward Yeah, I think he is saying he goes into the templates and modifies them to his liking.  I'm not a fan of doing it because then every time you upgrade you have to re-insert your changes.  I'm just not paid to futz wit the tool that much and it isn't my idea of a fun free-time activity! I've done many projects with both a traditional waterfall test team and integrated testers into our scrum team; never scrum with a test team.  I have to say that I can't imagine going back to an organization where the testing wasn't part of the team.  Quickly, my biggest complaint about the "old way" was that there was no shared goal between test and dev.  Dev's goal was to write code as quickly as possibly and throw it over the fence.  Testing's goal was to convince management that it wasn't ok to have developers using the "testing phase" to write new code.  Both just blamed each other.  The end result was that all bugs were "triaged" to determine if dev should lookat them.  By the time a developer saw it no one was sure if it still existed and certainly the offending code was no longer in frontal memory in the dev's head. Then I moved to scrum and now life is good.  Testing is part of the team and we share the common goal of delivering the stories (business value) each sprint.  No blaming.  After a lot of deliberation we ended up with the following: 1) Tester writes down defect on  a post-it; quickly. 2) Tester walks over to developer and discusses it.  If developer is not available or busy (I mean really into something important); then the tester holds onto the sticky and comes back later. 3)  If issue is simple (<1 hour), the developer fixes it on the spot.  I fix 90% of defects this way.  No recording waste necessary. 4)  If issue will take longer than that then it is recorded as a new SBI or added to an existing one as appropriate.  Hours are adjusted accordingly to affect the burndown.  We are very careful here because adding tasks that say you did another task wrong is kinda stupid.  Most of the time we move the existing SBI back to In-Proc and adjust the hours remaining.  Notice, this only works if the dev and tester are talking because neither one can correctly update TFS by themselves since each has a piece of the information. 5)  If defect is really a new story (like handling an edge case), then a new PBI is made for later prioritization.  Not added to sprint. 6)  If defect was found add-hoc then a new test case is written to cover it. Our goals were to 1)  fix bugs on the spot, when it is cheapest;  2)  Get direct communication between dev and test;  and 3)  reduce the cost of recording them which by its very nature is anti-lean (see Poppendick). We too had many people mention the "forget" problem.  The answer was that remebering stuff is a personal problem and that each person can do what they like to remeber what they need to (sticky, sharepoint, excel, whiteboard).  SFTS is a group tool with emphasis on planning not tracking and as such, items in it must benefit the group as whole.  It is not the place for personal reminders. Oh, and another thing that has taken a long time for everyone to get used to is that a lot of what we used to cal bugs in the old days are actually features in scrum :)  Ha!  What I mean is that the primary story only covers the 90% case usually and all of the other ways that a user can muck up the system is a load of other stories.  So "Save Data" is a story and "Validate data" is another and "click-click-back-click" is another.  This distinction alone probably has reduced "bugs" by 50% or more over what I have seen tracked as bugs in the past. Of course none of this would work the same with a distributed team and I wouldn't want to try. How does scrum work with a seperate test team?  Do you have the same commitment to the sprint and how do you achieve that?  I'm curious to see how this works out there. Cheers    Report

12-08-2008, 7:47 Haemoglobin Joined on 12-01-2008 Posts 5 Re: Bugs as a Product Backlog item seems awkward Sorry - by test team I actually meant they are part of the scrum team by your definition in that they are part of the sprint, helping the devs get what they set out to accept into the sprint over the line. We also were writing the defects on post-it's, however found that due to the nature of the application there were quite a few to write down, this was because it was an application re-write and any minor difference to the old version the tester would take note of - after all, the definition of done was an exact copy. However, being so many - a lot being unimportant differences it then became necessary to record somewhere a whole lot of low priority "deferred" defects that could be addressed in a later iteration if they were deemed important, otherwise we would never get anything over the line. I guess these could all be made into PBI's and prioritised but it seems really too much to have in there. Maybe they should be though, and all (hundreds) chucked low in the product backlog. Also, does anyone miss functionality for being able to drag a PBI up and down the product backlog (setting it's priority in the process) instead of having to type in a business priority number like 1320 to move things around? Limitation of TFS? :) Also, sometimes on the post-it note a lot of steps needed to be written down to reproduce the problem, and a resulting screenshot of the problem was sometimes useful. I just don't know if post-its can be enough alone to record testers results that's all - and speed and legibility is another thing, I know a lot of people are a lot faster and more legible typing than writing on post-its, and they aren't going to get lost or accidentally fall on the ground and trashed!    Report

03-10-2009, 6:44 Josh E. Joined on 03-03-2009 Chicago IL Posts 5 Re: Bugs as a Product Backlog item seems awkward Thanks for having this insightful discussion! Our team is in the process of codifying our implementation of Scrum as well as moving to TFS, and this site has been invaluable for guidance and support. I'd like to get some opinions on what we're looking at doing to address this issue. One option we're looking at (with the QA team of course) is to create a new Work Item Type based off of the Bug WI. We're calling it a Sprint Defect, and it will be a hybrid between a SBI and a BWI. Estimated Effort would be in hours, there would be an owned by, and it would require a link to a valid PBI. At the end of the sprint, or at QA lead's discretion, one or more Sprint Defects could be rolled into a BWI, which resides in the PB. Any opinions would be appreciated! Josh P.S. - I've got a preliminary checklist of the technical details needed to implement this, but I think that's beyond the scope of this particular post/board... still any feedback on that would be helpful also    Report

Scrum for Team ... » Scrum for Team ... » Scrum for Team ... » Bugs as a Product Backlog item seems awkward

(please select) Forums Home |- Search Forums |- Active Topics |- Unanswered Posts User Options |- Sign In |- Join this community |- Forgot Password Scrum for Team System |- Scrum for Team System - Announcements |- Scrum for Team System - Feature Suggestions |- Scrum Guidance Version 3.x - Team Foundation Server 2010 |- Scrum for Team System - V3 RC Discussions |- Scrum for Team System - V3.x Beta 2 Discussions Version 2.x - Team Foundation Server 2008 |- Scrum for Team System - v2.x Discussions |- Engineering Practices – v2.2 Reports Version 1.2 - Team Foundation Server 2005 |- Scrum for Team System - v1.x Discusions Task Board for Team System |- Task Board for Team System - Discussions |- Task Board for Team System Beta Discussions (Read Only)