Planning Overload with Almost Finished Tasks in Scrum

agileplanningscrumscrum-mastersprint

The case in question:

The sprint is almost over and one of my Scrum teams did not finish some tasks. (The reason for this is not essential for this question and will be addressed accordingly.)
One of them is a classic "90% done" case with a rather large number of story points and will be part of the next sprint – like in the question here.

We did backlog grooming and some preliminary estimation for the next sprint and discussed how to handle this unfinished task. While we all agree that it won't count towards this sprint's velocity, I argued that the we should not re-estimate the almost complete case with 1 instead of five story points, because I want the true complexity and the total work done to be still visible. And looking back the estimation was correct. – We are just transitioning to (scaled) agile and some management levels need to "see" that we are still productive in more ways than delivered products.

Obviously the velocity in this sprint will go down, but the transferred "already done" parts should rise it again next sprint.

So far we all agree.

But as our teams are rather small, four points is a big lump. I suggested that for this task only and with proper documentation we could consciously plan an overload of four points.

Is that a feasible approach or will I

run into problems I don't anticipate yet
set a bad example with a team that has been transferred to agile just a few months ago?

Best Answer

When a story isn't done at the end of the sprint, then the points of the story don't count towards the velocity of that sprint and the story goes back onto the backlog.

If during the planning of the next sprint the story is selected to be finished, then you can do a quick re-estimation of the remaining work. This estimate should only be used during the planning session to ensure that you are not under-loading the sprint with stories with a large number of points where actually very little works needs to be done to complete them.
On the board (and in the velocity of the new sprint), the original estimate of the story that was carried over should be used.

Such carried over stories is one reason why the velocity can vary from sprint to sprint and you should use an average to calculate the capacity of the team when planning a sprint.

If the non-completed story does not get picked up in the next sprint, then it might be better to plan it for the full points value when it does get picked up again, because it will also take time to get up-to-speed again with what the state was when the team stopped working on it.

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit.

I give you a couple of examples:

keyworded articles, which allow advertisers to have more effective adverts
CAPTCHAs, which are there to stop moderators having to deal with spam manually.

Most technical stories actually provide a business benefit, but it's rarely for the users. Phrasing them in a different way can help. I normally use Chris Matts' Feature Injection template:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

This explicitly recognises all kinds of stakeholders, including the development team. Now you can phrase your technical stories too, calling out the business benefit:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

I've written a couple of blog posts on this: They're not User Stories, and Feature Injection and handling technical stories. Hope they help.

Agile Sprint Planning – Handling Ungroomed User Stories

Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.

First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.

If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.

Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.

Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.

Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.

Best Answer

Related Solutions

How does a Scrum team account for infrastructure tasks in the planning meeting

Agile Sprint Planning – Handling Ungroomed User Stories

Related Topic