One of our scrum teams is giving it a try to create a canned story around end-of-sprint wrap up. It's just a holder wrapping up several tasks that are done at the end of every sprint. The part that is new is that they've started including story points that for that story. The points don't change from sprint to sprint.

Arguments were made for and against doing it this way:


  • It's already built into velocity, so it's not adding anything
  • It's "getting credit" for story points that aren't for real stories


  • It is an added measure of precision that should help with forecasting
  • It gets the team credit for work that was done

Is this practice of capturing story points for sprint overhead work a positive, negative, or neutral? (Maybe there's a better way to ask that question.)

  • 1
    What is this "end-of-sprint wrap up"? Is this stuff that should be part of your Definition of Done for Product Backlog Items that isn't?
    – Thomas Owens
    Commented Jun 28, 2018 at 19:52
  • @ThomasOwens It includes tasks such as DoD for the sprint, sprint review staging w/ PO, and final merging of branches into master. Commented Jun 29, 2018 at 17:05
  • @GaTechThomas The Definition of Done should be applied to Product Backlog Items individually and should be written in a way that, when a Product Backlog Item that satisfies the DoD is integrated, you have a working Increment. The Sprint Review should be an Event and shouldn't be given an estimate. The final merging should just be part of your deployment process and doesn't need to be given an estimate either.
    – Thomas Owens
    Commented Jun 29, 2018 at 17:08
  • The team has a DoD per Product Backlog Item and a DoD for the sprint. This is not part of sprint Review. It is actual checks that are done to ensure that the sprint is wrapped up for real. The parts that can be automated are automated. Commented Jun 29, 2018 at 19:14

5 Answers 5


If you look at your pros and cons, you don't actually have pros and cons. The first point in each actually contradict each other - in con is says it adds nothing and in pro is says it adds precision. The second point is literally the exact same thing case as a pro and a con.

Personally, I would opt to not put story points on it because I think your con on the first point was right. It adds nothing. Worse, I think it actually reduces precision and hurts forecasting.

Story points are a valuable measure of product delivered, not simply of work done. If it was work done, we'd get story points for meetings, designs, etc. So completing 30 story points really means you've delivered 30 story points worth of product. I assume these end-of-sprint tasks are some sort housekeeping. Ultimately, the way I know it isn't product is that it accrues every sprint. If it is a 5 point backlog item, every sprint would just push my target 5 points further away. Also, if it was product, I could choose not to do it, substituting some other backlog item instead. I think putting points on these items actually hurts my forecasting and adds nothing, unless you're trying to "get credit" and then we have a completely different conversation on our hands.

  • 1
    "Story points are a valuable measure of product delivered, not simply of work done" - Are you sure? Isn't it rather a measure of cost? Consider two items that deliver the same customer outcome, one estimated at 3 Points the other 15 Points. Should we choose the latter to maximise the amount of product delivered, or the former to maximise ROI and increase our capacity to deliver other customer outcomes?
    – onedaywhen
    Commented Jun 29, 2018 at 8:26
  • 1
    Great point. I didn't mean to suggest that story points represent a value measurement.
    – Daniel
    Commented Jun 29, 2018 at 10:35

Story points and velocity exist for one reason only, to allow teams to estimate the capacity of future sprints.

If story points are being seen as 'credit' for work completed then you have some deeper issues to worry about, such as how your organisation is definining the success of a sprint. If a team does lots of work and delivers loads of story points in a sprint but there is little business value generated should they be receiving 'credit'?

Also, what are the tasks that need to be done to wrap up a sprint? If they repeat every sprint then I would be asking the team:

  • Are they really necessary?
  • Why have we not automated them?
  • Comment added to initial question that provides a bit of detail about the tasks. Commented Jun 29, 2018 at 17:07
  • It would definitely be worth considering doing a regular merge from master into your branches. Ideally do this from continuous integration every day. That way, the final merge from the branches into master is trivial and can just be an automated step in the release process. Commented Jun 29, 2018 at 18:14
  • It's as automated as is reasonable. The part that is not automated is the final merge. Someone has to click the button. At times in the past, that has been forgotten, so the team creates tasks on day 1 to ensure that everything is done done. Commented Jun 29, 2018 at 19:17

Strictly speaking, the stories on a scrum or Kanban board should describe work that adds value to the product the customer is expecting. I work to prevent "to do" items from appearing on the board. It clutters the board needlessly and makes it difficult for the team to say focused on the actual work. This challenge can be particularly acute with remote teams who are relying on an electronic version of the board to help organize their work and communication. It slows down the stand-ups and, in extreme cases, causes team members to ignore the board because most of what's on there doesn't apply to them.

From previous comments it also sounds like these tasks rightfully belong as acceptance criteria or definitions of done for various stories.

As for points, the intent and purpose behind their use is to establish a measure for the effort needed to complete a story. In the simplest of terms, this would be everything except time. How complex is the work? Does it involve new technology? What are the dependencies on other stories? How does the story fit within the product vision and customer expectations? What are the risks (time, cost, complexity, etc.)? There are many, many questions that could be asked to determine the position on the backlog for a story and the story points to capture the effort to complete the story.

In summary, find a way to either incorporate the "end-of-sprint" tasks into appropriate stories or keep an off-the-board checklist to run through at the end of each sprint.

  • These are not story-specific tasks. They are tasks that need to be done as part of the sprint. Are you saying that no story or showing DoD tasks should go on the board? Where do technical debt tasks go? How do these things slow down standups? Do you not create tasks spawned by acceptance criteria and track them on the board? Commented Jun 30, 2018 at 21:24
  • Could you please list specific examples of such tasks? For example, technical debt: certain elements should be fixed as part of stories, others should be represented in business terms so that be clear for Product Owner why he needs them. For example, done teams call Non Functional Requirements as Technical Debt: improve performance, improve usability, improve maintainability of certain functionality. Commented Jul 1, 2018 at 1:56
  • Some of the items are mentioned in the comments in the original question. Technical debt items that are complex are captured as stories, but small items, usually bugs, are worked in the sprint as individual tasks. Is there a better way? In any case, the original intent of this question is about sprint-level wrap up items, so I think I've strayed into scope creep land. Commented Jul 1, 2018 at 14:52

I agree with others that you should not put story points on the tasks.

I can also propose you to put the tasks as a column in the end of your board with Explicit Process Policy that features should be collected in the column while not all features are complete and the end-of-sprint tasks are complete.

  • What would be gained by adding a new column/state? Commented Jun 30, 2018 at 21:07
  • 1
    In such case it will be more clear why features stuck in the end of sprint not being moved to Done column. The column should be called somehow like "Merge & Integrate". Without the column you will need to have corresponding artifical tasks every sprint. Commented Jul 1, 2018 at 1:49

In Scrum, as described in the Scrum Guide, you should not have a separate product backlog item for wrap up activities, as this work should be included in the product backlog items that is part of the sprint's increment (it is not "Done" if there are remaining wrap up work). Therefore the wrap up should not have story points of its own, if story points is your way of estimating the product backlog.

You could (and should) have Sprint Backlog Items for these type of activities and if you're estimating the sprint backlog items these activities could have its own estimate as part of the sprint backlog.

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.