Re: [scrumdevelopment] Don't burn the last day?
- Hi Jean,
This generally happens when the team updates amongst themselves in the following manner during standups-
1. What I did YESTERDAY
2. What I will do TODAY
Instead the team should adopt the below patter-
1. What I did since the PREVIOUS STANDUP
2. What I will do until the NEXT STANDUP
Now, if we have the daily scrum standup in the morning, then the team would have an update to share even for the review and retro day as they had a good part of the previous days update to share amongst themselves.
If the daily standups are towards the end of the day, then the team would not have an update for the review and retro day as it has already been shared by the end of the previous day.
Please refer to the manual burndown attached herewith. Here the blue line is the ideal burndown and the red line is actual. Note that the ideal burndown is flat for the first day of the sprint as we have the standups in the morning. If the standups are kept for the end of the day then the ideal burndown would begin on Thurday and end of the 2nd Tuesday of the sprint(flat line on the last day of the sprint).
Generally, the team has a stand up before they get into the review meeting to complete their burndown. The remaining tasks(if any) are carried forward to the retro and planning if required.
In either cases, we will have 9 standups during the sprint.
Hope my mail clarifies. :)
CSM, PSM I
From: Jean Richardson <jean@...>
Sent: Saturday, September 29, 2012 5:28 AM
Subject: [scrumdevelopment] Don't burn the last day?
I’m working with a Team that uses one of the more ubiquitous tools to track their sprints and roll up with about 35 other Teams for enterprise reporting. This one Team is interested in editing their burndown so that the last day (Review and Retro day) is removed from the burndown because “we don’t really do any work that day anyway.”I’m thinking of all kinds of reasons this would be a bad idea. Has anyone ever seen this be to the good? Anyone aware of sources that talk about this particular choice?--- JeanJean RichardsonAzure Gate Consulting~ Repatterning the Human Experience of Work(503) 788-8998
- I'm just a little worried that they are focusing on the reports and tools, as opposed to the working software. Here's another question for them-how would they work and plan if they had NO burn down chart?
Jean Richardson <jean@...> wrote:
Yup, that’s the question. Monday will be interesting. Last I heard, they felt this would help them plan.
I wonder, how would modifying the burn down help their understanding of what they are doing or need to do for a given sprint?
Jean Richardson <jean@...> wrote:
I don’t think this team is competitive with other teams in the organization. I *think* they’re trying to get a more accurate burndown, but, frankly, the trend has been pretty clear on their burndowns in the past.
“Useless” might be a strong term. Burndowns are relatively gross measures. The trend on their burndown is a pretty accurate reflection of their actual delivery.
This team, overall, has a tendency to concentrate on details over getting started: Their user stories have evolved into mini-BRUP, including implementation notes, designs, and test plans before the team is willing to story point.
That aside, I’m interested to hear about anyone having experience with, for instance, dropping day 15 from the burndown in a three-week sprint. All things considered, has anyone seen value here.
It may be interesting to note that this team is one of 38 teams in the org, and they are all using the same tool to track their sprints. This team is the only one that would deviate. We have the latitude to optimize process locally, and if org pushback comes down along the lines of “this will mess up our reporting at the exec level,” I’d be happy to stand up to that. However, it seems to me that if this IS a good idea, why aren’t we all doing it? I don’t know that I’ve seen discussions on this previously. Have we all just missed something?
Sounds like your team got a good point - if the final RRP day is entirely taken up by the RRP activities, it should not be included in their capacity-planning either.
The sprint burndown should be a very simple means of tracking ideal-vs-actual progress throughout the sprint. For that it neads to be realistic, including only the real work days. For that means, I would not include weekends in it either. Only actual work days ("business-days") available for producing code during the sprint.
Including the last (non-working) day in the burndown will probably bring on negative pressure to achieve unrealistic goals, inhibit team success and demotivate them or at least render the burndown quite useless.
--- In email@example.com, "Jean Richardson" <jean@...> wrote:
> I'm working with a Team that uses one of the more ubiquitous tools to track
> their sprints and roll up with about 35 other Teams for enterprise
> reporting. This one Team is interested in editing their burndown so that
> the last day (Review and Retro day) is removed from the burndown because "we
> don't really do any work that day anyway."
> I'm thinking of all kinds of reasons this would be a bad idea. Has anyone
> ever seen this be to the good? Anyone aware of sources that talk about this
> particular choice?
> --- Jean
> Description: gate.site.jpg
> Jean Richardson
> Azure Gate Consulting
> ~ Repatterning the Human Experience of Work
> (503) 788-8998