Story points for "end-of-sprint task" items?

Question

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:

Con:

• 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

Pro:

• 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.)

Answer 1

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.

Answer 2

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?

Answer 3

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.

2¢

Answer 4

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.

Answer 5

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.