0

I have a question regarding the incomplete acceptance criteria in a sprint.

A user story is said to be completed if all the acceptance criteria are satisfied. There can be multiple acceptance criteria for each user story. Some acceptance criteria may not be able to be completed, due to incomplete development or late development. Usually, we clone the user story and move it to the next sprint for tracking. However, there is a chance of some acceptance criteria being completed while some are not. So this process is difficult to track.

Do you have any workaround to track the incomplete tasks in the next sprint?

Improve this question

4 Answers 4

Reset to default
3

Usually, we clone the user story and move it to the next sprint for tracking.

Don't do that.

The story isn't done. If you put it to Done and clone it, your velocity will be messed up. It will look as if you completed work, when you didn't. This will cause you to overestimate in the future, because velocity reports mistakenly show you being able to complete more work than you really can.

there is a chance of some acceptance criteria being completed while some are not.

So add columns/statuses representing the acceptance criteria. Only move it to the rightmost Done column once all criteria have passed. If the Sprint ends while the story isn't yet Done, just leave it. JIRA should move it to your Product Backlog automatically upon ending the Sprint.

Afterwards, you should evaluate the story as normal in the Sprint Planning Meeting. Re-estimate/re-prioritize it as normal.

Should we move the incomplete stories to product backlog[?]

Yes.

This will underestimate the points in [the sprint where the stories were not completed].

Nope. You did not complete the work. You accomplished 0 story points for that story. So your burndown chart will show that story having not been burned down.

This is correct.

As far as Scrum is concerned, a story that is 90% done provides 0 business value, and is therefore treated the same as 0% done. Your velocity should only take into account the amount of Done story points you can complete in a Sprint.

Just make sure you re-estimate the story before including it in a new Sprint. If an originally 13-point story is 90% done, it should only be 1 point for the new Sprint.

Improve this answer
11
  • Thanks sarov for your valuable points. I am really confused on moving the incomplete user stories to product backlog. We may already spend some time on that incomplete story and moving to product backlog will underestimate the points in the particular sprint. I am not sure whether I understood your response. Let me explain. Suppose we are in sprint 12 and some stories are not completed. Should we move the incomplete stories to product backlog. This will underestimate the points in sprint 12. Basically I am trying to understand the better ways to track these situations in JIRA
    – Jithin Antony
    Commented Oct 16, 2018 at 15:35
  • @JithinAntony All stories on the product backlog are re-estimated. What matters is the amount of work remaining to deliver the story, not the amount of effort previously expended on it.
    – Todd A. Jacobs ♦
    Commented Oct 16, 2018 at 23:00
  • You had me up until 're-estimate'. Velocity is only useful as a measure over time. Don't re-estimate. I am in agreement with Mike Cohn. I teach all teams not to re-estimate since, what you have effectively done, is vanish 12 points from the scope of the project and your baseline story is messed up. Just my opinion but I don't care if the 13 points are captured in Sprint A, B or C or even D. Over the course of 5 Sprints they will appear somewhere. That is what counts. Velocity over time. If we have 10 stories total. All 13 points. And all of them are incomplete..and re-estimated..
    – Venture2099
    Commented Oct 17, 2018 at 11:06
  • ..suddenly your project has shrunk to 10 points from 130. (An extreme example but illustrative none the less.) A stakeholder takes a look and says.."Gee whiz, developing a hyperdoodle is only 10 points of work! Golly! I can expect a hyperdoodle every 10 points! "
    – Venture2099
    Commented Oct 17, 2018 at 11:07
  • @Venture2099 No, because velocity is not a measure of productivity or value. It is intended as a predictive measure of how much work can be delivered within a single iteration. Truncation and re-estimation generally yield more useful results than complex smoothing functions, and at a lower cognitive cost. Carrying estimates forward is typically a way to account for expended effort, or a mistaken attempt to treat velocity as a measure of value delivered, Reasonable people can disagree about agile practices, but the Scrum framework calls for re-estimation at Sprint boundaries.
    – Todd A. Jacobs ♦
    Commented Oct 17, 2018 at 12:46
5

As you are referring to sprints and user stories, I will assume you are using the Scrum framework.

Within Scrum, there is no such thing as a partially complete user story. A user story can either be done, in which case all acceptance criteria and the definition-of-done have been fulfilled, or the user story is not done.
When, at the end of a sprint, some stories are not done then those stories should be moved in their entirety to the product backlog to be re-planned along with the rest of the backlog.

Once the team thinks that a user story is done, that is when it must be verified that all acceptance criteria have been met.

If it is a frequent occurrence that you have user stories with partially completed acceptance criteria and that partial set of acceptance criteria by itself provides value to the business (i.e., you have a better product to show to your stakeholders), then it might be that your stories can be decomposed further into smaller stories.

If this is the case, I would recommend you to try to split those stories until it is no longer possible to add value with only a subset of the acceptance criteria.

Improve this answer
1
  • 1
    +1 for releasing stories that all AC have not been met and raising a new user story to cover off the remainder of the work..*if* the work is releasable and has value in it's current state.
    – Venture2099
    Commented Oct 17, 2018 at 11:09
1

I recommend establishing a function to denote done acceptance criteria from undone acceptance criteria in each card. This can be done by simply using italics, boldening, coloring, checkboxes, etc. to help separate what acceptance criteria is done from acceptance criteria that is incomplete. Once a piece of the acceptance criteria is met, someone on the team should update the card to somehow visualize that the piece has been satisfied. This information can and should be visualized and inspected at the daily scrum to see what work needs to be considered as your team moves towards its sprint goal(s).

Improve this answer
1

Totally agree with Sarov's response re: don't mark Stories as done if they are not.

Consider also whether your Stories are too big. Are all those acceptance criteria required for the minimum delivery of that Story? Maybe consider making the Stories a little smaller. You will get more "done" in each Sprint timebox and still be delivering a valuable product.

Improve this answer

Your Answer

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

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