Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

New forum(s) for tools like TFS?
Last Post 01 Apr 2014 02:40 AM by Ludwig Harsch. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Franck van der Sluijs
New Member
New Member
Posts:22
Franck van der Sluijs

--
22 Mar 2014 01:00 PM
    Is it possible to add a forum for “Scrum tools” with a sub forum for “TFS and Visual Studio”, or only one of these forums?

    We are using TFS with the Scrum template and I’ve some questions. E.g. do we need “fix” and “test” tasks for every Bug item? When a bug is found for a PBI on the current sprint, do we need to add a bug item or a new task for the PBI, etc. etc.
    Simon Reindl
    New Member
    New Member
    Posts:45
    Simon Reindl

    --
    22 Mar 2014 10:57 PM
    Hi,
    These are great questions, and highlight the need to be mindful when using a tool - so that you use it the way you want to; and are not coerced in to doing anything you don't think correct.
    Most tools have a degree of flexibility in them.
    When do you create a bug
    I suggest that you should create a bug only when you absolutely have to, and aim for finishing a sprint with zero (0) bugs. So create a bug when:
    1. It is found in an environment outside of the Sprint (Live)
    2. You need to remember what you were up to for the next day, or after the weekend
    3. It is too much work to fix within your Sprint, and the Product Owner accepts the rest of the PBI apart from the bug

    After that, the bug is a special form of PBI.
    So you create tasks that are necessary to get it to "Done" and track it as you would any other work.

    Regards
    Simon
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    24 Mar 2014 12:13 AM
    > When a bug is found for a PBI on the current sprint, do we need to add a bug item or a new task for the PBI, etc. etc.

    No, you need to fix the bug and find out how it arose and how long it was there before it was detected. Then you can potentially improve your process.

    The leanest way to handle this is to prioritize an in-sprint defect fix before any other Sprint Backlog items are progressed. That's the spirit behind the "andon" system and single piece flow. What you *don't* want is an in-sprint defect tracking system, as that just supports the accumulation of waste - a queue of rework, as the Poppendieck's have put it. When a defect is identified for work in progress, the best thing to do is to immediately fix it so depreciation and technical debt are minimized.

    You can raise in-sprint defects as tasks against a story if you like, as long as you don't turn the Sprint Backlog into some sort of register of accumulated rework for future actioning.

    As Simon points out, defects discovered after an increment has been accepted are effectively new PBI's. They should be triaged to the Product Backlog for prioritization by the Product Owner.
    Franck van der Sluijs
    New Member
    New Member
    Posts:22
    Franck van der Sluijs

    --
    27 Mar 2014 01:19 PM
    Thanks for the answers.

    I had a discussion with the QA manager of our organization. He wants that testers add Bug items and not Tasks to the Sprint Backlog, when a bug is found for PBI of the Sprint Backlog.

    My manager tries to find a compromise and suggests defining a custom work item in TFS to register a ‘BugTask’, the same as a task but used to register bugs for PBI’s that have no unfinished development tasks.

    In my opinion PBI’s on the Sprint Backlog are not Done before the Product Owner declares that they are done in the Sprint Review meeting. That means no bugs can be reported for PBI’s on the Sprint Backlog before the Sprint Review meeting. Is this right?
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    01 Apr 2014 02:40 AM
    Hi Franck,
    I think the main problem here is that your development team doesn'nt own its process. Instead, you have an external QA manager, who obviously needs some help in understanding the difference between a sprint in Scrum and a testing phase in waterfall.
    What is the reason he wants the testers to create bugs? Are they not part of the team, maybe not even in the same building, so he thinks a tool works better than individuals and processes? You should include them into the team in that case. The next step would be to have developers write tests while developing (or even before). There is no such thing as a tester in Scrum ;)
    You are not authorized to post a reply.


    Feedback