Our website will be undergoing scheduled maintenance today, Monday, September 25th between 4:00pm and 4:30pm US Eastern Time (20:00 - 20:30 UTC). The site may be unavailable during this period, so we ask that you please plan accordingly. This notification will be removed once maintenance has ended.
software in 30 days - Work Breakdown figure 2.4 explanation
I'm new to Scrum and reading up about it. I have bought Schwaber and Sutherland's Software In 30 days and have hit a stumbling block. I am obviously missing something so wondered if one of you more experienced Scrum users could guide me and tell me what I have misunderstood.
On Page 23-25 it outlines and describes the Work Burndown. The textual descriptions are fine for me but when I look at figure 2.4 Work Burndown it does not make sense to me.
On page 23 the book states "...The units are ordered by sequence in which you want them turned into usable functionality. Let's say the order top down is 2,3,5,3 and 8 still."
On page 24 the book explains further and in paragraph 5 states. "...The development team created 3,5 and 5 units of functionality in the first three periods of time. The resulting chart is shown in figure 2.4"
Now what confuses me is if I look at the y-axis (requirements) the units plotted are 21 8,3,5,3 8. My question is this how did these figures end up here? It is not the plan work burndown or I would expect 2,3,5,3 and 8. And, it is not the actual Work Breakdown of the development team doing 3,5,3 because where is the 8?
Am I making sense?
Any advice and clarrification much appreciated.
If the description is correct then the y-axis of the Work Burndown figure should state the following planned work (top down): 21 (total amount of work), 2 (not 8 as displayed now), 3, 5, 3 and 8.
Just be ware that in the Kindle version the numbers are misaligned on the y-axis. In addition, if the requirements are delivered in the planned order you would first deliver 2 (the first requirement) or subsequently maybe 5 when you're also able to complete the second requirement. Not 3 units of work as described because requirements are either done or not done.
Related to your issue I have encountered a few more inconsistencies later in the book for which I like a response from readers:
> page 72 - sprint meetings are proportionate to the length of a sprint but the numbers in Figure 6.6 imply that shorter sprints result in relative longer sprint meetings;
> page 84 - the Quality and Studio Return measurements in Figure 7.6 table don't match with the diagrams in Figure 7.4 and 7.5;
> page 84: I don't understand the high # of Projects (560?) in Figure 7.6.
I think it would be best if Ken answered the questions here. I would have to rely on my personal interpretation for some of them.
i think i got an answer for your question related to figure 6.6 on page 72: You are right that the length (Timebox) of Scrum Meetings (expect Daily Scrum) are proportionate to the length of a sprint. But the table shows the number (not the time) of meetings you have on a project of a fixed length with X sprints. The more sprints you have the more meetings you got and more money is spend on this meetings.
Related to your second question i think this is just a failure or the graphs are net related.
On your last question I would say that # of Projects is an absolute number - not relative to the previous Quarter. So from Quarter 8 to Quarter 9 there where 300 new Projects beeing monitored.
But those are only my personal interpretations of the book :-)
I would also like to add another question: On page 176, Figure A3.2 shows three Subsystem Teams. Two of them are starting with "Sprint 1" on "Month 1" but Subsystem Team A starts with Sprint 4 on Month 1. Why? Did they work in Month -2, -1 and 0?