Agile/scrum - tracking time spent in current iteration towards stories from the next iteration if all current stories are done

Question

Our team has been slowly trying to go towards agile, and like many other teams, up to this point, the question of "what do we do when we actually finish all commitments?" is fairly new and foreign to us. But lately it actually came up once or twice.

The reason I wanted to ask this board on good practices is that we are using Rally for agile project tracking and one thing the tool does is keep track of hours and points. In order to improve our estimates, I wanted to do something with this data and provide feedback to the team on how we did in the past, by comparing metrics that show estimated task hours vs. actual task hours vs. assigned story points.

This seems like it could work great as long as developers work up until the last day of the iteration or if they are late with their deliveries. Then "actual hours" reflects exactly what went into each story.

However, what should we do when we finish early but next story would take too long to complete so we can't pull it into the current iteration?

I know some people are advised to simply take the time for general cleanup/housekeeping like updating automated tests or documentation, but for sake of argument, let's say the best value to the team and the company in this specific scenario would be to immediately start working on the next story.

If we are not committed to the next story, actual hours aren't tracked anywhere. And in the next iteration when we do commit, we will only identify estimated/actual hours which will go into the next iteration, at which point the work might already be 25%-50% complete.

Answer 1

Things I would look for in order of preference:

1. Does anyone else need help finishing up their work in the current sprint? It's better to try and make sure that everything that was targeted in this sprint is actually completed (keep the whole team together in this sprint) than to let the faster developers move on to future stories (letting everyone get spread out across multiple iterations). Remember that the scrum process has process that needs to happen before and after each sprint, and if you start spreading these activities across sprints, the whole process will lose its "cyclical" quality. I think the cyclical nature of scrum is one of the subtle things that makes it attractive. But that's just me.
2. Are there any stories designated for future sprints that still have more risk than people are comfortable with? If you have a project of any size, then there are bound to be a few stories that people are not entirely sure how something is going to be done. You may need to ask the team for feedback on this. Use the extra time to reduce risk on those stories by prototyping, doing additional research, or whatever you need to do to make everyone comfortable with the problem stories or break them down further.
3. Is there a very small story that can be pulled into this sprint and absolutely be finished by the end of this sprint. If so, then pull it in.

Answer 2

The problem with general cleanup and housekeeping in some corporate cultures is that they simply get ignored, or viewed as something "extra" that doesn't necessarily need to be done.

In order for the sprint to actually be complete, consider for a moment that the estimates for that story should also include documentation, reducing technical debt, updating automated tests, etc. Consider that your sprint is not "done" until these things are also completed.

Ignoring these things may lead to additional risks to the quality or success of the project and could be considered an impediment down the road.

With that said, if you have your mind set on skipping these things, you could split the next story up into smaller components so that the first part could be finished in the extra time remaining, but the extra work you would be putting into this may create some confusion in the team. My suggestion would be to stick to your sprints and don't rush. It will pay off in the end.

Answer 3

While hours actual feels like something valuable to get to better estimates, its actually useful if you are using relative estimation.

The point of using story points and a time box is to learn, "how many points of work can we fit in the box". This works as long as we get good at relatively estimating all 5s and 5s and 3s as 3s, instead of that will take us X time. The better you get at identifying the size of story, then the more stable your average velocity will be, which means you are pretty good at estimating what you can do in 2 weeks.

It is always variable so yes, sometimes you take to much and sometimes you take to little and you assess that with your burndown everyday. Based on the assessment its up to you how to act. Fix a few bugs, learn something, pull in a small story you know you can finish. There is no scrum by the book answer here, just good judgement.

Why not spend the time that you were going to use to become better estimators to adopt a new practice? (look at XP for ideas). Don't fall into the traditional earned value trap that we can become better at estimating time. It's not possible. Our brain can't do it, hence relative estimating.

Good luck! Sounds like you are doing great so far.

Erin

Answer 4

A big alarm bell went off as I read this question. It sounds a lot like you are allowing your tool constrain your teams working practices which is usually bad ju-ju.

Work out how your team wants to manage this situation (and there's some good advice in the other answers), then figure out how to track it, even if it means doing something manual, it's better than forcing the team into an approach because it's what the software allows.