The System that Supports the Process
“If everyone is moving forward together, success will take care of itself.”
Henry Ford
Chapter Purpose
As an Agile Coach and Agile Scrum Practitioner,
I will describe in detail the components of the Agile Scrum Infrastructure. Specifically a deep dive will be taken into User Stories, The Agile Tree Hierarchy, the AgileScrumTeam, Ceremonies, and the Burn Down Chart
So that ScrumMasters, ProductOwners, DevelopmentTeam, and TestTeam members can understand what the infrastructure is behind Agile Scrum.
Introduction
What I have come to realize after years of using Agile Scrum is that teams grow over time in the use of Agile Scrum. And as the teams mature, the more Agile Scrum processes they have in place, making them even more effective. The key systems they all have in common are:
• User Stories
• Ceremonies
• Story Pointing
• Burn Down Chart
These three systems represent the minimum level of conceptual knowledge needed to be effective in the use of Agile Scrum. Executing well on these items is essential to seeing any benefit from Agile Scrum. So, please continue reading in order to understand these areas even more.
User Stories
Learning about User Stories is critical because they are the main component of Agile Scrum. No matter what you are doing on an Agile ScrumTeam, it all relates back to User Stories. Now that you know a bit about User Stories, here are some expectations User Stories should meet:
• They should facilitate the creation of a working code that meets the needs of a stakeholder, where the value of asked-for change is in excess of the investment.
• Convey information to the reader about what needs to get done, in the way it was meant by the writer to be interpreted
• Decomposed to the point where their estimated duration can fit within the time-box of an iteration.
• They are sufficiently descriptive to support the creation of test cases.
The template for User Stories, which the founders of Agile Scrum created, is brilliantly constructed. It is easy to learn, easy to remember, and forces a User Story creator to capture a well-carved slice of meaning from its parent User Story. But, just to be sure they accomplish their core function, User Stories should be reviewed by a peer to ensure, to the greatest extent, that the User Story conveys the intended meaning. And, before they are accepted into an iteration, the DevelopmentTeam and TestTeam need to agree that the User Stories are meaningful and complete.
Below, please find an explanation of the three parts of a User Story. I am doing this so that those who use User Stories can better understand how to be effective in writing and in using them:
As a
Describes the “who” is asking for the work to be done. This has three purposes;
• If the creator of the User Story is ever needed for consultation, it provides a clue to the home organization of the initiator.
• This part provides context for understanding what the person is asking for.
• It makes the creator focus on their perspective, or role, they are taking on when they create each User Story. That is, it forces the User Story writer to take on a specific perspective.
I want
The words “I want” steers the User Story writer to explicitly spell out what they have in mind. This “ask” is to be within the “scope” of the performing organization’s vision statement, and the mission statement of the AgileScrumTeam. Another value to this is that it clearly calls out the work that is supposed to add business value.
So that
“So that” is the part of the template which describes the reason for the User Story, in terms of value-addition to the business. It can either be qualitative or quantitative. I feel this supports the creation of excellent test cases, test scripts, and acceptance criteria. Also, this will describe the end use of the User Story, which will further explain the use of the “I Want” part.
Please note that during iteration planning, the DevelopmentTeam and/or TestTeam should have the option of not picking up User Stories to work on if they are not useable. If defective User Stories are committed to and brought into an iteration, then they will likely destroy any cadence that the team has developed. And, this would also erode trust as the same ProductOwner who encouraged the team to accept incomplete User Stories will be the first to get mad at the team when it cannot deliver.
Ceremonies
Ceremonies are similar to meetings, but have a specific purpose based on which ceremony is being executed. Each has its own expected result, which does not change. Some ceremonies fall on specific days in the Agile cycle, and they are to be placed onto all ScrumTeamMember’s Outlook calendars, and scheduled out for a very long time. This will eventually result in AgileScrumTeam members having this time marked out for the Ceremonies, and, they will from a habit behavior of getting ready and showing up, prepared.
As for when to hold the Ceremonies with respect to the Iteration cycle, I like to hold the Backlog Grooming and Iteration planning a few days before the Iteration starts. And then, holding the Demo and Retrospective on the last day of the iteration works quite well. The Daily Stand Up, and Parking Lot is to take place, without fail, once per business day; preferably at the start of the work day. All team members are expected to attend the Day Standup.
Please find below a chart that outlines how I like to schedule Ceremonies in relationship to an iteration. The assumption is that we are using a 2-week Iteration Cycle, starting on a Monday.
Day of Week |
Iteration Day |
Ceremonies for Current Iteration |
Ceremonies for Next Iteration |
Any |
As needed |
Vision |
N/A |
Wednesday |
−3 (can also take place on demand) |
Backlog Grooming |
Thursday |
−2 |
Iteration Planning |
N/A |
Monday |
1 |
Daily Standup + Parking Lot |
N/A |
Tuesday |
2 |
Daily Standup + Parking Lot |
N/A |
Wednesday |
3 |
Daily Standup + Parking Lot |
N/A |
Thursday |
4 |
Daily Standup+ Parking Lot |
N/A |
Friday |
5 |
Daily Standup (Halfway through the iteration+ Parking Lot |
N/A |
Monday |
6 |
Daily Standup (Last Monday of Iteration) + Parking Lot |
N/A |
Tuesday |
7 |
Daily Standup + Parking Lot |
Start Backlog Grooming for next iteration Wrap up visioning for next Iteration |
Wednesday |
8 |
Daily Standup + Parking Lot, |
Start Iteration Planning for next cycle |
9 |
Daily Standup, Parking Lot, identify all User Stories for the Demo, and do a Dry run of the demo. EOD (End of Day) is the cut-off for approval of items in the Demo. |
Continue Iteration Planning for next cycle |
Friday |
10 |
Daily Standup, Parking Lot, Retrospective, and Demo |
Complete Iteration planning for next iteration |
Please find below a list of ceremonies and related information. As a friendly reminder, the more of these Ceremonies that are performed, and performed correctly, the more you will see the benefits of Agile Scrum:
Story Pointing
The idea of Story Pointing is to create, at a macro level, a rough planning estimate. The easiest way to explain Story Pointing is to assume that all participants in a Story Point meeting are co-located, and are in the same meeting room to create Story Points for User Stories. They are only allowed to estimate using the numbers 1, 2, 3, 5, 8, 13, 21, 34 … (for the mathematically inclined people reading this, this unusual number sequence is closely based on the Fibonacci sequence).
The team picks a well-understood User Story, of average duration. A Story Point of “8” is then associated with that average User Story, this is called the “pivot.”
Then, the ScrumMaster shows the team a new User Story to estimate. Here is an exhibit of the numbers to apply Story Points to User stories:
How This One Relates to the Pivot |
User Story’s Story Point Value |
Clearly larger than the pivot User Story |
21 or 34 or higher |
A little bigger than the pivot User Story |
13 |
Pretty much the same as the pivot User Story |
8 |
Somewhat smaller than the pivot User Story |
5 or 3 |
A lot smaller than the pivot User Story, it would be rare to find a User Story for this effort less than this number. |
1 |
Comment: Ceremonies that support the iteration, and are explicitly tied to the iteration’s cycle, should be scheduled immediately after a team determines the duration of its iterations. This way, all team members can plan to attend well in advance of the cyclically held ceremony.
Story Points are stored along with the other metadata in the related User Story. The main point here is that the estimate is being created by “relative sizing.” No “hours” or “days” are used in this process. Remembering that human behavior is to hear a dollar value and stick to it, using Story Points removes this attachment to an early estimate as you cannot really assign a dollar value to something so arbitrary. However, with respect to Iteration capacity considerations, Story Points have proven to work just fine.
A word of warning. It would not be all that hard to map Story Point values to estimate hours. If you do this, you will corrupt the value of “relative” sizing and you could find yourself being locked into providing a premature, solid estimate.
A number that is needed to make Story Points work is called “Velocity.” Velocity is the total number of Story Points that can be accepted in an Iteration by an AgileScrumTeam. This number is unique to each AgileScrumTeam and the AgileScrumTeam can change the Velocity from Iteration to Iteration. The team determines this number by taking a guess as to how many Story Points of work they can process in an Iteration. For example, I am writing this in early January. What we did with my AgileScrumTeam in December was to reduce our velocity significantly as many people were on long vacations around the holidays.
For example, let us say that one step in the project from Chapter 2 is to take off the tires of a car to install the devices that can start stinking if a car moves faster than 75 miles/hour. That seems pretty simple as a good mechanic can pull off tires in about 10 or less minutes. Compared to our Pivot User Story, I think that would qualify for a Story Point of 1. As for filling out all the paperwork and forms needed to find and use a race track for the car to go over the 75 miles/hour mark, that is no easier nor harder than any other user story; so I would give that the same value as the pivot User Story, a value of 8.
An obvious question is, how do hours ever fit in? Well, the User Stories that are small enough to be completed in one iteration, are further decomposed one last time, by the BuildTeam. This last decomposition results in “Tasks.” Tasks are what the BuildTeam uses to complete work, and, hours or days are the time unit associated with those.
Burn Down Chart
A burn down chart shows how much of your available time you have used as a team, as compared to a line that assumes a constant use of hours, at the same level, each day.
To understand time in a project sense, you need to understand the two distinct terms Effort and Duration. Effort is a term from the classical project management community. It means how many hours that are actually spent working on task. Duration is a related term; it means how much time passes while working on an assigned task, whether the resource is actively engaged on task or not. For example, presume “Terri” is working on one task, on and off for 4 days. So:
• Under Duration time reporting, the 4 days would be included in the time she was working on the assigned task. This is the type of estimate used during Story Pointing.
• Under Effort driven time reporting, she would report only time on task. This is the type of estimate that is done when you are estimating at a Task level.
How to build a Burn Down Chart
Here are our assumptions:
• You are a ScrumMaster.
• There are three people on your team, and each starts with 80 estimated hours of actual on task work effort hours, across an iteration that lasts 2 weeks.
• All actual and estimated hours are effort hours, and are pulled from estimates entered onto tasks. (These estimates and actuals are supplied by the people doing the work.)
• The person doing the work supplied the initial estimate, and on a daily basis will supply an estimate of the work left to be done.
First, we shall use the above information to draw what I call the “Perfect Burn Down Line.” This is the line that assumes that all work happens at a constant pace until all hours are used up when the Iteration ends.
• So at the start of the first iteration, we have 240 hours worth of work to do (80 * 3), that is, 80 hours times 3 people. This assumes they are on task from the minute they walk in the door, till the time they leave work 8 hours later.
• We have 10 business days in the iteration.
• We have 0 hours left of estimated hours at the end of the iteration.
This graph represents a perfect burn down. It is what I use to gauge performance against during an iteration:
Comment: The above is the Perfect Burn Down Line. It is based on the Effort hours accepted into an iteration. The assumption is that a perfect Iteration would eat up and equal number of hours in a day, and there would be no hours available at the end of the Iteration.
Comment: This is quite rare! This is the case where a team is on schedule for the entirety of the Iteration.
Comment: This means no one is working on the iteration. The ScrumMaster needs to talk to the BuildTeam!
Comment: When the work left is above the Perfect Burn Down Line, and all information is accurately reflected in the Burn Down Chart, this team is behind schedule.
Comment: In Burn Down Charts, when the hours left to complete line is below the Perfect Burn Down Line, this means the team is ahead of schedule. At the start of day 4, it is apparent that the team is comfortably ahead of schedule. Were I ScrumMaster, I would find out why the sudden drop in effort hours took place. I would suspect the team did something brilliant to get so far ahead. Once out, if my guess was correct, I would share the success, of the AgileScrumTeam, widely.
Comment: When the work left line is below the perfect burn down line, and all information is accurately reflected in the Burn Down Chart, the team is ahead of schedule.
How this is used:
When I started a ScrumTeam in the middle of summer, I realized it was actually an accomplishment to have a working Burn Down chart to look at. About the middle of the second Iteration it was in good enough condition to start using it for its intended purpose. A working Burn Down Chart is a signal that the team is functioning well in terms of adopting the Agile Scrum Process as many items need to take place, correctly, for the Burn Down Chart to work well.
Where I use it is at the start of our official Daily Standup, I briefly show it, and call out anything that the Burn Down chart is showing. My current AgileScrumTeam is composed of AgileCoaches. The only issue we ever really have, which the burn down chart shows, is a slow start on iterations. But even that is improving over time.
With an ALCM, any executive who wants to invest a few minutes to understand how to use the ALCM to pull statuses can easily pull a status on any AgileScrumTeam. This means that all AgileScrumTeam members must keep their time information up to date, or it is only a matter of time before the ScrumMaster gets an unpleasant phone call.
A Warning
There is a special case of the Burn Down Chart that you should be aware of. Let us propose that there are only 2 days left of the iteration, up until now your team was on schedule, and then your team learns that a massive defect is discovered in the architecture you based your work effort on. In other words, there is now a sink-hole of time to invest, and no one was previously aware of the massive time investment. This would mean:
• this chart was fine until this point,
• the burn down chart was telling the stakeholder community that everything was in good shape,
• there was nothing to worry about, right up until there are just 2 days left.
Then on the next to last day of the iteration, the chart suddenly displays a huge disparity between planned and actual. Be aware that this chart can only display what is known, and reasonably expected. Meaning, just because a burn down chart paints a rosy picture for 80% of an iteration does NOT mean the last 20 percent will be easy-peasy.
An example was when we had 4 days left to our last iteration of the release, and then results from friendly user testing came in with 20 defects that needed to get fixed. That significantly changed our burn down chart, quite unexpectedly.
Summary
In summary, this chapter identified the minimum infrastructure necessary to have an AgileScrumTeam function. We covered Ceremonies, Story Points, and Burn Down charts. After a team is comfortable with these systems, progress in realizing the value of Agile Scrum should take place.
Knowledge Reinforcement
1. Assume that you are about to take a trip for pleasure to Madagascar. What is your Epic level User Story, and then break the Epic up into four smaller user stories which address that is needed.
2. If in the middle of an iteration it is discovered that a User Story is too large for a release, who should the DevelopmentTeam and/or TestTeam member notify?
3. Why is it important to put User Stories into the provided format?
4. There is a new project. Which member of the Agile Scrum Team is are most likely to bring the project to the AgileScrumTeam?
5. Who is most responsible for creating quality User Stories that relate directly to a project.
6. What is the last time that a team can say no to working a User Story that is in the wrong format, lacks clarity and has wrong or misleading metadata?
7. Class Discussion: If a ProductOwner is too busy to attend the team’s Ceremonies, especially Backlog Grooming and Vision: what can be done to better engage the Product Owner? Please note, if you ever look at the calendar of a Product Owner, you will see that they are at back-to-back meetings all day. This is because these people are a critical asset to the performing organization as a whole.
8. (Class discussion) Assume that you are training a new member of a team; the new and improved ScrumMaster! She wants to make a list of everything she should learn to be effective when she takes over in 3 weeks. What would you recommend being on the list? How can you use this list in your day-to-day operations with your AgileScrumTeam.
9. After a few years of using Agile Scrum, you are pretty sure you can map Story Point numbers to hours. Would this be a good thing?
10. Assume the following:
Iteration |
Story Point Value Completed in Iteration |
2 |
10 |
3 |
25 |
4 |
31 |
5 |
29 |
6 |
30 |
What would you pick as the Velocity going forward, and why? (comment: there are many potential correct answers to this).
11. A contractor wants to use Story Points in a variable cost contract to determine cost to you. That is, as the AgileScrumTeam you are thinking about hiring estimates Story Points, and then completes Story Pointed User Stories, you then get charged per Story Point completed. Is this a good idea for you? Why or why not?
12. Given the three Burn Down Charts below, which Agile ScrumTeam needs the most help right now? Assume both charts are up-to-date.
