Speak freely

DoD: Assign an item to two independent (team) iterations: Development + QA + Deployment / Backend + Frontend etc. with split metrics

I want to create 2 separate iterations for developer and QA
we have a list of iterations , no overlap
Developer will go 1 iteration ahead for QA
With our process, on Dev iteration, Coding means done.
On QA iteration, we will commit to fix bugs for some entities (those entities can be "Open" or "Coding done" on start day, but it must be Accepted on end date.

We're trying workarounds with iteration + team iteration or with custom fields of type 'Targetprocess iteration' but we encounter several obstacles and limitations with available relations, filtering and reporting.

58 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Phuong Le shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    9 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Grégoire Bélorgey commented  ·   ·  Flag as inappropriate

        We recently started using points instead of ideal time on one of our pojects, and one issue we have is that the burndown in points doesn't take completion into account unless the story is in a Done state.

        Our Definition of Done requires validation from the PO, so we consider the team's work is done when the story is in Testing. Is there any way to configure the burndown to meet our needs ?

      • Anonymous commented  ·   ·  Flag as inappropriate

        Hi there

        we need to change the done so that burndown charts count things in columns prior to done as done for the burndown - ie we want the last two columns to be used to manage deployment but burndown charts to work based on say the 2nd last column.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I see that the burn down of user stories are only noted to complete when we set it to Done Status, which makes sense from begining to End of Sprint. But is there a burn down of when developers are completed
        For example, I have a two week sprint. One week developers need to complete by Friday. The next week our QA team is needs to complete the following Friday.
        Overall, is there a burn down for when developers complete by Friday, and another Burn Down for QA the next week.

      • Anonymous commented  ·   ·  Flag as inappropriate

        We have cases when the same US appears in 2 releases/iterations, one for frontend and another for backend. How to process User Story when we have Front End and Back End assigned? who should be responsible to change the state? How should it calculate time spent efforts?

      • Alain Origlia commented  ·   ·  Flag as inappropriate

        I'd like to know why when I add a Test Plan Run assigned to QA with some effort, I see no impact on my current iteration burndown? Thanks

      • Yuri Nosenko commented  ·   ·  Flag as inappropriate

        We are currently at the end of our sprint. Most of the work is either done or "in testing".
        So, when we look at our burn down chart we still see about 80 points remaining, and most of those are in testing.
        So, this chart is misleading in a way, because most of the work has passed through development, but the chart still says we have 80 points left.
        we were wondering if there was a way to show a line on the chart for just developers
        one thought we had was to have a burn down with two lines: done = done, and done = no longer in development

      • Anonymous commented  ·   ·  Flag as inappropriate

        We are running multiple projects with staggered sprints. I have a team of around 12 developers + multiple PMs and QA. We have a 3 month release cycle. In any given release typically multiple developers work on a single 'feature', and we have multiple features targetted to a release. The nature of the work is such that not all feature teams start their sprints at the same time. So, the scenario for a release could be -

        Release 10.5
        - Feature 1
        - Dev 1
        - Dec 2
        - QA 1
        - PM1

        - Feature 2
        - Dev 3
        - Dev 1
        - QA 2
        - PM1

        ....

        Also, note that depending on the nature of workloads, we may add/ remove devs from a feature after finishing a sprint. The main challenge defining sprints is that -
        1. 1 User can be working on many features.
        2. I cannot have multiple 'fixed' teams.
        3. Not all sprints start on the same day.

        Currently I am creating multiple teams, but this just gets too messy and confusing very soon.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Hi, I'm really stuck and wondering what the best solution will be. Our situation is that we have many projects and a technology team which has back-end, front-end and test developers, designers and a QA. Now I dont know if i should go for Multiple separate teams, or put everyone in the same team (Technology) then had separate Team Sprints, like Front Team Sprint and another Back Team Sprint. Both Team Sprints would have dependancies to one another, and the same projects would be found on both sides but some sides will have independant projects to. We could desynchronise the iterations if we wanted but probably not, we don't know yet. The front side creates the specs for the back-end to work on, but the back-end could have other requirements that are forced by the API (that is part of the back-end side). Anyways i don't know how to do this and I believe we need to reduce the size of our members per scrum team. Our product owner which i believe should be more user centric, would mostly focus on the front iterations as the back-end would take it's tasks from the requirements coming from the front. Can you please help me figure the best setup. Thanks

      • Maxwell Correya commented  ·   ·  Flag as inappropriate

        Once development is complete, there shall be next scrum/iteration release for QA; where QA shall execute Functional and Regression Test Plan’s; and defects recorded at each level shall be recorded separately and action shall be planned out.

      Feedback and Knowledge Base