PO marks unfinished stories as "done" before re-estimating remaining work
Hey people,
first of all let me say Hi. I'm a very new scrum master with lots of book knowledge but very little street smarts, as it were.
My problem is as follows:
My team regularly fails to finish their backlog (as an example, this sprint they 'finished' 31 SP and have 29 remaining,) which is a problem in and of itself, but one I feel confident in adressing myself. For now! ;)
The issue is that my PO is adamant about taking unfinished backlog items, marking them as "done" and then creating new, smaller stories to add to the next sprint.
What compounds the issue is that we're a distributed team, and we only have Jira to work with (no physical board.)
Please correct me if I am wrong, but I find this practice is not very agile, for the following reasons:
1) It impedes transparency. I can not accuretly see how much work got Done in past sprints, for example. How much value was really achieved? How many of them are done 100%? Have 31 storypoints been done 70%? 29 points 80% done and 2 points 20% done? How many points can we really achieve next sprint?
2) It creates a "waterfall" effect where sprints blur into each other, and the demarcation becomes arbitrary. If backlog items regularly exist across sprints, why have sprints at all? Why not work one item after another and have regular estimation meetings? (I'm sure we all know the answer to those questions! ;) )
How do I convince my PO to stop this practice? Is it even necessary? And how would we implement another solution in Jira? (Jira has this problem of not making Tasks visible enough, imho)
Thank you very much for your time and thought!
Hi Max,
I just saw this old post hadn't been answered.
I'm not sure if you are talking about the PO changing the plan, or just performing a load of admin in Jira. But for the purpose of this answer, I will assume the former.
The issue is that my PO is adamant about taking unfinished backlog items, marking them as "done" and then creating new, smaller stories to add to the next sprint.
What is meant by "Done"? Specifically, is the Product Owner claiming that these are "done" work as part of the product Increment? Are the Development Team being compelled in any way to include work that doesn't meet the definition of "Done" in any Increment that they produce?
It is entirely legitimate for a Product Owner to remove items from the Product Backlog at any time, and a Product Owner should not be compelled to retain any in-progress items. The end of a Sprint could be considered a good time for the Product Owner to apply lessons learned from the Sprint, and adjust the Product Backlog accordingly.
What happens with the "new, smaller stories" that the PO creates? Do the Development Team get to refine and estimate them? If not, how does the PO know that this work is smaller?
If incomplete work is being closed without being done, it should be possible to mark that separately in Jira, such as by setting the appropriate value in the "resolution" field, or by having another closed status that is distinct from "Done". It should then be possible to identify what was done.
2) It creates a "waterfall" effect where sprints blur into each other, and the demarcation becomes arbitrary. If backlog items regularly exist across sprints, why have sprints at all? Why not work one item after another and have regular estimation meetings? (I'm sure we all know the answer to those questions! ;) )
Actually, I don't see how you have come to that conclusion. From what you have said, the Product Owner is using the Sprint end as a moment to change direction, and adjust the plan for the subsequent Sprint. In my experience, it's more common for teams to just let incomplete work spill over to the next Sprint.
It seems your PO is consciously using the timebox of each Sprint.
Whether this is a valuable approach will depend on the situation.
The issue is that my PO is adamant about taking unfinished backlog items, marking them as "done" and then creating new, smaller stories to add to the next sprint.
Does he or she consider the work to be of release quality, and if so are increments being released into production at least once per Sprint?
The issue is that my PO is adamant about taking unfinished backlog items, marking them as "done" and then creating new, smaller stories to add to the next sprint.
This sounds like a valid interpretation of the Product Owner's duties if they are seeing this as acceptable enough to be included in the potentially releasable increment. Since they are creating stories in the backlog for anything that is still needed then they are maintaining the body of work that needs to be done on the product.
How many of them are done 100%? Have 31 storypoints been done 70%? 29 points 80% done and 2 points 20% done? How many points can we really achieve next sprint?
Now you are getting into the age old conversation about how to use velocity. My opinion in this case it to let the Development Team decide that as they are the ones responsible for the Sprint Backlog. If you feel the need to report this to them, tell them how many they actually completed and how many they didn't. Because that is the real truth of their sprint efforts. Don't try to compensate for what they are doing.
The lesson I'd focus on with the Development Team is refinement. It is apparent that they are not learning that they tend to over-estimate their ability to finish work, under-estimate the effort for doing individual stories, or are not fully understanding the stories so that they can accurately break the stories into sizes that can be completed during a single sprint. I think that would be a better use of your time as a Scrum Master than trying to manipulate the velocity calculations.