3

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?
  • Why do you so care about time estimates if you don't use them? – Sergey Kudryavtsev Jul 25 '17 at 7:22
  • The structure of our teams are that they have stories and they break it down to several tasks, so a story might takes more than one sprint while people are working on different tasks below the story. In this way" story point based burn down chart "can't show any progress during the sprint. ( since the story might takes multiple sprints). That's why I need to work with remaining time based burn down chart. Do you have any idea what would be the best solution for our team? – panyvi Jul 26 '17 at 21:06
3

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.

  • 1
    I'd agree with your first point, but disagree with your second -- a story point burndown chart can be very useful. While it won't track quite as nicely (it will have "steps" rather than a curve, it can help to make sure you're close to where you need to be for a successful Sprint. – JDRoger Jul 25 '17 at 13:44
  • 1
    Thanks. That is what I meant. Wrong phrasing. Edited the answer to reflect the story point suggestion. – mta Jul 25 '17 at 13:54
  • Thanks for the answer. The structure of our teams are that they have stories and they break it down to several tasks, so a story might takes more than one sprint while people are working on different tasks below the story. In this way story point based burn down chart can't show any progress during the sprint. ( since the story might takes multiple sprints). That's why I need to work with remaining time based burn down chart. Do you have any idea what would be the best solution for our team? – panyvi Jul 26 '17 at 21:07
  • Well, you either break stories, so that they fit or just talk about actual progress even though the burn-down won't pick the changes. I wouldn't worry too much about this. Use the chart for trends rather than for super accurate tracking. – mta Jul 27 '17 at 10:32
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:

enter image description here 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.

  • Thanks for the answer.The structure of our teams are that they have stories and they break it down to several tasks, so a story might takes more than one sprint while people are working on different tasks below the story. In this way story point based burn down chart can't show any progress during the sprint. ( since the story might takes multiple sprints). That's why I need to work with (remaining time based burn down chart). Do you have any idea what would be the best solution for our team? – panyvi Jul 26 '17 at 21:09
  • 1
    In that case you need to add second layer of estimation. Estimate your tasks by time and use these estimations for tracking progress during Sprint. As for Story Points, you can still use them for Release Burndown Chart. – Sergey Kudryavtsev Jul 27 '17 at 7:00
  • I have updated my answer. Please, update your question too. Your comment strongly clarifies the original question. – Sergey Kudryavtsev Jul 27 '17 at 7:51
0

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.

  • Thanks for the answer. The structure of our teams are that they have stories and they break it down to several tasks, so a story might takes more than one sprint while people are working on different tasks below the story. In this way story point based burn down chart can't show any progress during the sprint. ( since the story might takes multiple sprints). That's why I need to work with remaining time based burn down chart. Do you have any idea what would be the best solution for our team? – panyvi Jul 26 '17 at 21:08
  • We do similar things in my current organisation, however we use Epics to capture the larger multi sprint groups and we try to ensure all stories are broken down to a level where it can be delivered in a sprint ( things still carry over from time to time. We manage releases when Epics are delivered. We still estimate future epic delivery off story points. We only use the hours to manage the sprint ... i.e. if you allocate 40 hours of tasks but your capacity is 30 hours then we know you are over allocated for this sprint. Future release forecasting is still via Velocity & Story points, – Andy L Jul 27 '17 at 14:04
0

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.

  • Thanks for the answerThe structure of our teams are that they have stories and they break it down to several tasks, so a story might takes more than one sprint while people are working on different tasks below the story. In this way story point based burn down chart can't show any progress during the sprint. ( since the story might takes multiple sprints). That's why I need to work with remaining time based burn down chart. Do you have any idea what would be the best solution for our team? – panyvi Jul 26 '17 at 21:09
  • It is common practice to break stories down in to several tasks, but the aim should always be to fit all the tasks for a story in a sprint. You may want to consider either reducing the size of your stories so they fit in a sprint or increasing the sprint length. JIRA allows you to do the burndown in time instead of in story points, which can be useful if you have large stories that only get finished towards the end of the sprint. – Barnaby Golden Jul 27 '17 at 8:12

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.