Timeline for Do we need to update time estimates when we estimate based on story points?
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 27, 2017 at 14:04 | comment | added | Andy L | 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, | |
| Jul 26, 2017 at 21:08 | comment | added | panyvi | 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? | |
| Jul 25, 2017 at 7:48 | history | answered | Andy L | CC BY-SA 3.0 |