What to do with a task in next sprint....which is "finished" but not "done"
Hi! My name is Peter, nice to meet you.
In my new team is usually to have this problem and i have doubts how we should to do in this case. To stay in context, we have a board with the next states:
To Do | In progress | Blocked | Peer Review | In review | Done
OK....so the problem is many times when the finish date sprint arrive, we have some task in "In review" pending of testing QA so the task is not en PRO yet, so is not done. We finish the sprint and we start the next one... What we have to do in this case?
In this moment, my team mates REESTIMATE the Story Point of this "Finished but not Donde task" to 0 Story Point, because they have all the task developed and just we have to wait QA team test the task. Their argument is that if you keep the original story point, for example, 3, the effort in the new sprint is not real because the task is really finished (unless QA reopened...). Thinking about that, maybe they have reason because the new effort of this task in the new sprint won't be 3...for sure is less than 3.
For other hand, i think the more correct to keep the original story point, 3. They told me that if we decided to do this, we are telling we are going to "do" 3 story point that are not real... but i say, what is the problem? In the same way to make an effort in the previus sprint but you cant see this effort in the burndown chart because the task is not done...now you count this task like 3 even if you have almost finished the task.
Remember the task is not halfway...so we want to split the task...we just are waiting for QA test.
What do you think?
Thank you very much!
Peter
Unless you complete all tasks (Including QA), your story would not be in DONE stage. That means you have not developed something releasable that can add value till QA and other check points in DOD gets checked.
Please remember- The use of story point is just to analyze how much work we can take up in sprint. That's it .
One good thing is your team re-estimates. But, both the approaches ( keeping story points 0 OR keeping original story points 3) are wrong. You need to re-estimate depending upon the efforts required for remaining activities. In this case QA. It may need 1 story point only, so ideally it should be 1.
Remember that the task is not in the middle ... so we want to divide the task ... we are just waiting for the quality control test.
If QA is not tested, the task is not completed, so that task would not be adding value and had not met the DOD. In that case you have two options, you keep it as a technical debt or add it to the Sprint Planing so that the part that is needed is estimated
First question is what does your Definition of Done say about the need for testing? From your description I'm assuming that the QA team is not part of your Scrum Team. And I ask, why not? If the team does not have all the necessary skills to deliver an increment then they are not in control of the work. How could they reasonably provide a "done" increment if they are not doing all of the work?
I also feel that there is a misunderstanding of what story points mean. They are an estimation tool. You do not get credit for them. But that isn't the real issue here so I'll leave that discussion for later.
The real issue here isn't reestimating stories. It is an impediment that your team is facing in getting work done. If they are dependent on work done by people outside of the Scrum Team then you as Scrum Master should be helping to remove that impediment.
the problem is many times when the finish date sprint arrive, we have some task in "In review" pending of testing QA so the task is not en PRO yet, so is not done. We finish the sprint and we start the next one... What we have to do in this case?
Presumably the tasks were planned to meet a Sprint Goal. That was their purpose, and the purpose of Sprinting in the first place. So: was the Sprint Goal achieved or not?
First at all, thank you everyone!
Ok, i think i understand the problem. I will try to do that QA member will be part in scrum team, because in effect, in this momento, QA is a team apart from our squads, and have their our organization and is an error.
I supposed, always is possible one day a task cant be tested in time, so of course, the task IS NOT DONE. So i think we have to add the task to next sprint, and estimate the story points we think QA need to test the task.
Thank you!
If you cannot arrange for QA to be part of the team, then your organization needs to take a hard look at the Definition of Done and how they feel being agile is adding to the ability to deliver product to the stakeholders. Your description seems very waterfall to me. Your development does work, qa tests it, development fixes problems, qa tests again and at some point it gets passed through the gate to production. Just because you use all of the terms and take advantage of some of the events of Scrum does not mean you are doing Scrum.
How you can possibly know (as a team, if you estimate) is it 0 points, remain the same or is not grater? Especially if you haven't QA in your team? What if after testing it turns out to be much more complex? What if you will be in the middle of the next sprint? Which work be more important to do? Current one, or old one that just returned form QA?
I am with Ian in this, the purpose of Sprint is to achieve the Sprint Goal, not to move as many PBIs as possible to the "Done" state - that won't necessarily bring value to the product. So the main question is: Was the Sprint Goal achieved or not?
Returning to your description, I sometimes tempt to be as strict as possible. You can not change if you constantly avoid feeling pain. In my understanding if the team drops the undone / unfinished work behind the "QA" fence, and simply move on to do new task on a daily basis, then everybody in the equation avoid feeling valuable pain that could motivate everyone to change, therefore you will only prolong this limbo state and create zombie-Scrum in the process.
Replace the "In Review" step with "Resolved".
Review is part of development and so is test so it's all "In Progress" don't differentiate or else it will lead to Mini-Waterfall i.e. testing becomes someone elses job outside of development, not good.
Open -> In Progress -> Resolved -> Done.
Resolved -> Done step requires the PO or stakeholder to see the demo and agree that it has met DoD.