Do we need to update time estimates when we estimate based on story points?

Question

We estimate the issues based on story points/planning poker. My questions are:

1. Do we need to update original/remaining time estimates when we estimate based on the story points?
2. If we estimate based on story points, then we need to look at the burndown chart based on story points and not remaining time estimates?

Answer 1

Do we need to update original/remaining time estimates when we estimate based on the story points?

I'd say no. Filling time information will result in people looking at different metrics. It will defeat the purpose of using story points as an estimate technique.

If we estimate based on story points, then we need to look at the burndown chart based on story points and not remaining time estimates?

Yes. Stick to story points if that is your selected method.

Since you put in the work to do planning poker sessions and size the tasks this way, then stick to it while working on those tasks.

Answer 2

Do we need to update original/remaining time estimates when we estimate based on the story points?

In case if you don't use time estimates, why do you need to update these fields? Just don't use them.

If we estimate based on story points, then we need to look at the burndown chart based on story points and not remaining time estimates?

The same. If you don't use time estimates your suggestion is correct.

UPDATE

---

First of all, to not fit User Stories in a Sprint is bad practice. One of the main benefit of Scrum is fast feedback from customers. That's the reason, why business want to have "done" functionality after each Sprint.

About your problem: we use 2 level of estimation (you can read more here: Why use both story points and hours?) and use both metrics within Sprint Burndown Chart:

Yes, it was not well finished Sprint for us =)

So, legend:

• Red line is for tasks and represents man-days versus time.
• Blue line is for stories and represents story points versus time.

But in your case you can use only time-based metric (i.e. man-days) for tracking Sprint progress (yes, in that case you should start to estimate tasks). As for Story Points, use them for tracking something more high level (Release progress, for example).

---

P.S. Another solution (and it is much better): try to make your User Stories small enough to fit them to Sprints. This question "What we should do with tasks which estimated time bigger than sprint?" may help you to do this. After that you can use story-point-based Sprint Burndown Chart without any problem.

Answer 3

Do we need to update time estimates when we estimate based on story points?

The simple answer is no. Some projects are run with both story points and hourly task estimates. But if your's isn't then there is no requirement to use the time fields.

Answer 4

I work with some teams that estimate in story points for stories and in time for sub-tasks.

The reasons they do this are:

• They find that doing time-based estimates on sub-tasks helps them with their design and analysis. The estimates themselves aren't valuable, but the process of estimating is.
• They use the time estimates on sub-tasks to ensure no team members are overloaded. For example, if they have a team specialist (like a designer) then they add up the sub-tasks they are likely to work on and make sure they haven't given them too much (or too little) to do.
• They like to keep sub-tasks below 1 day. Hence they do a lightweight estimate on each sub-task and ensure it is a good size.

An obvious disadvantage of this approach is longer planning meetings. As such, it is important that the teams trade-off the benefits they get against the cost. Not all of the teams have found it worthwhile, but some have.