3

We have finished a story which is no longer required by the Product Owner (PO) or Management. The completed story is not going to add any business value. What should we do in this case? Should we count the effort in our velocity or not?

Improve this question
4
  • At what point in the lifecycle of the story did de PO decide (and communicate) that the story is no longer needed? While the story was still on the product backlog, after adding it to a sprint, after the work started, at completion of the story, after completion of the story?
    – Bart van Ingen Schenau
    Dec 8, 2017 at 11:38
  • At completion of the story
    – ssharma
    Dec 8, 2017 at 17:19
  • 1
    I suppose it might have added business value if the implementation itself clarified to PO/Mgmt that it was no longer needed..
    – Vicki Laidler
    Dec 9, 2017 at 4:57
  • Your question has been edited to make it clearer and more grammatical. However, it's unclear whether the "pivotal-tracker" tag adds meaningful context or not, since the question should be answerable regardless of your tool. On the other hand, Pivotal is rather opinionated, so you may want to look at this related answer about Pivotal Tracker's approach to velocity, too.
    – Todd A. Jacobs ♦
    Dec 10, 2017 at 14:03

2 Answers 2

Reset to default
4

We have finished a story which is no more required by PO/Management. Surely this story is not going to add any business value. What to do in this case? Should we count the effort in velocity or not?

Velocity is primarily (and most effectively) a metric for estimating a team's capacity to do future work within a Sprint or series of Sprints, and is not intended to be a measure of productivity or business value. Because it estimates future capacity based on historical performance, you should take that into account when determining how to track your velocity.

In your specific case, which is rather sparse on detail, I would suggest the following rules of thumb:

  1. If the story was taken on at the start of the Sprint during Sprint Planning, and if the work was delivered at the end of the Sprint in accordance with the Definition of Done, then the work is legitimately counted towards velocity because it correctly expresses work planned/completed during the Sprint.

  2. Likewise, if the story lost its value during the Sprint for some reason, but the Product Owner chose not to take it out of scope or terminate the Sprint early as a result, then the work still properly measures the team's capacity to deliver work.

  3. If the story was not completed in accordance with the Definition of Done, then the work can not be counted towards the team's velocity.

  4. If the Sprint Goal was achieved, whether or not the Product Owner asked for it to be removed from the Sprint, then whether or not to count the work towards velocity basically comes down to how you wish to communicate about the velocity metric: as planned/completed work, or as a value or opportunity cost. Obviously, I lean towards the former, but some practitioners may legitimately disagree.

On the one hand, counting work towards velocity reflects planned work completed. On the other hand, not counting it makes invalidated work visible as a drag on velocity.

As long as you aren't making the fundamental error of trying to make velocity reflect effort or time expended, and are consistent in your use of the velocity metric to communicate about the status of the project, then how the team deals with a one-off situation like this shouldn't have much impact on a velocity metric expressed as a range or trailing average.

There are certainly exceptions, such as very short projects or framework implementation failures, but in general this should be a non-event that's addressed in the Sprint Retrospective. However, your mileage may vary.

Improve this answer
1

Great learning opportunity

If the work was done based on the PO prioritizing the work, yes you should count it in velocity. It is possible market conditions changed.

If the dev team went ahead on their own, then you cannot count it in velocity. Key takeaway is to tighten up your process and take up work only if prioritized by the PO.

If there was a misunderstanding between the PO and dev team, then you should tighten up your communication and feedback.

Regardless, this is a great learning opportunity. It is time for a retrospective to identify the root cause and come up with ways to avoid a similar debacle again.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.