Let's say a project has 2 or more Sprints and for each sprint you are using a burn down chart to track the Sprint progress. If at the end of the first Sprint there are tasks that have been started but are not completed and hence will go into the next sprint to be worked on how would those tasks be handled in the next sprint burn down chart - do you adjust the estimated time for the tasks to reflect the fact that some work has been done on them or use the original estimated time? Thanks.
2
-
1Closely related: pm.stackexchange.com/q/15707/4271– Todd A. Jacobs ♦Commented Jun 14, 2017 at 0:02
-
1Read what Mike Cohn thinks: mountaingoatsoftware.com/blog/…– NathanCommented Jun 14, 2017 at 11:57
Add a comment
|
3 Answers
I've tried both with my Team. The one we found to make more sense is to adjust the estimate. The whole idea of Agile is to update your plan based on new information. Updating your estimates to reflect the work remaining for your Stories will make estimation much easier, and will better reflect what is actually happening in Sprint 2.
The only thing you've really 'lost' is the overall effort that was required for that Story, but it was decided (in our case) that we didn't really even need that.
-
Good answer. We've found that it also helps to just use Story Point burndown charts in some cases, rather than time.– JDRogerCommented Jun 13, 2017 at 16:53
-
1Upvoted as a good answer. However, other than for retrospective purposes, I'd go further and say that tracking effort expended rather than effort remaining is a Scrum anti-pattern growing out of the CYA principle rather than an agile one.– Todd A. Jacobs ♦Commented Jun 14, 2017 at 0:59
TL:DR: Use the original estimate. It keeps your data consistent, holds the team accountable and reflects the actual nature of work in a Scrum setting.
This answer is based on making a living as a full-time agile coach and having experienced both the healthy and unhealthy ways to deal with unfinished work.
Why: One of the great things about agile is its binary nature for tracking work. Work is either Done or Not Done. There is no ambiguity to this. At the end of the sprint, the story is "potentially shippable" or it is effectively "not even started". There is never a grey area of "Oh we're 90% done" and then be 90% done for three sprints.
Caveat: I'm going to talk about Shu level Scrum, or "starting scrum". As a team gets too high performing (or Ri level) they can start experimenting with the basics. Until they do, I always recommend you start with the basics. The reason is there is 30+ years behind why those basics work. If you've got issue with this premise, I recommend Ron Jefferies "We Tried Baseball, it Didn't Work" Blog.
First off, when you reach the end of the sprint, everything is moved from the sprint backlog to the product backlog. Planning starts all over. It's been two weeks and the Product Owner needs to prioritize the backlog based on the current reality. Even though the team just spent two weeks on something, it may no longer be a priority and the product owner may decide to drop it. This is 100% okay, it's not sunk cost. Instead, it's realizing something isn't valuable anymore and deciding not to ship it and thus incur the cost of supporting it. A company I worked for once ended up over a barrel with eBay because they'd deployed this "cute" feature, that didn't really work which eBay then ended up relying on for mission critical business. They ended up having to support this poor feature for over a decade.
Next up, you don't re-estimate work in progress. There are a number of reasons. The top of the list is the rest of the world didn't just sit still for the last two weeks. Even if the story is "90% done" (see above), it hasn't been deployed and I know of very few systems that don't change over the course of two weeks. That code is likely out of date to the current system. You need to go back through the whole story and make sure it works with today's environment.
Re-estimating will also completely shred you velocity metrics. This will lower the team's ability to predictably plan the work.
End of the day, if you are not finishing stories in a sprint, you need to be asking why not putting a bandaid on the problem and moving forward. Make your stories smaller, plan less work, fix your release process, whatever is. Just don't re-estimate.
Oh and don't split the story into done and not done work. That's a whole other agile anti-pattern.
answered Jun 13, 2017 at 19:33
-
thanks for your input. The team lost almost a couple days of work effort working on an emergency. My concern here is that lets say one of the tasks was originally estimated for 5 hours of effort and 3 hours have already been used in the past sprint. Assuming in the current sprint the developer spends another 1 hr on hte task and actually completes it - my concern with having that task in the sprint 2 with the original estimate is that it may significantly skew the Burn down chart Sprint Adherence data. Commented Jun 13, 2017 at 19:58
-
1@Joel Bancroft-Connors "Re-estimating will [...] lower the team's ability to predictably plan the work." I'm having trouble understanding... why. I mean, obviously, if you just mindlessly go "We estimated it taking 5 days and we're about 80% done, so there's 1 day left" then yeah, that won't work. But that's not re-estimating; that's just taking bits off your original estimate. Why would actual re-estimating, that is, looking at all your new information and creating a (more!) realistic estimate for that work lower predictability?– SarovCommented Jun 13, 2017 at 20:15
-
1@Sarov It's a longer explanation that I can fit in 500 characters. Good metrics look at starting points, ending points, and the trends. If you're changing your points at the end of the sprint, it corrupts the data. This is one of the lesser reasons not to. It's the not focusing on "Getting to Done" that is the greater issue. Commented Jun 13, 2017 at 21:42
-
@KTBFFH First off, don't estimate in hours. Almost no point in estimating if you use hours. Too long to explain here. Second, don't sweat a few points here and there. A single sprint's data is not what we care about for estimating. What we want is multi-sprint trends and with those, a couple points here and there isn't important. It's the greater trend. Guess I should blog on this some more. Commented Jun 13, 2017 at 21:44
-
1
TL;DR
A Sprint burn-down chart tracks work remaining, not work completed. If you want to track work completed, use a burn-up chart instead.
Inspect-and-Adapt Incomplete Work
The fourth value of the Agile Manifesto is responding to change over following a plan. Carrying work forward automatically not only violates the time-boxing principle that underpins the Scrum framework, but it also reduces a team's ability to adapt to evolving requirements.
When implemented properly, work in Scrum is never carried forward automatically from Sprint to Sprint. Increments of work, whether done or not-done, must always be inspected and adapted at time-box boundaries. Any work that is incomplete at the end of a Sprint is placed back onto the Product Backlog, where the Product Owner can reprioritize it (or even discard it altogether) based on changing business needs or the current Sprint Goal.
The next time the work is in scope for Sprint Planning, the team replans and re-estimates the work based on new information, current context, and level of effort remaining to complete the work. While lessons learned about the work from previous Sprints can inform the estimation process, historical estimates are discarded as irrelevant to the current time-box.
See Also
The following answers are related, although the questions they address are not necessarily exact duplicates of the one you're currently asking. They offer additional explanation and guidance about the importance of re-estimation and replanning.
answered Jun 14, 2017 at 0:55
