WHAT IS SCRUM? – PART 2

Thanks to International Scrum Institute for their support to the content of this article.

In the first part of this article we talked in general about Scrum Framework, and Scrum Roles, in this part we will cover more details about Scrum. I this Article:

• THE SCRUM PRODUCT BACKLOG
• SCRUM USER STORIES
• ESTIMATIONS – PLANNING POKER
• DEFINITION OF DONE (DoD)
• SCRUM BURNDOWN CHART

THE SCRUM PRODUCT BACKLOG

Back to top↑
The Scrum Product Backlog is simply a list of all things that needs to be done within the project. These items can be technical requirements, functional requirements, or  bugs, and they are represented  in the form of user stories. The Product Owner own’s the Scrum Product Backlog, he/she is responsible of maintaining it. The Product Owner uses the Scrum Product Backlog during the Sprint Planning Meeting to discuss with the team the highest priority items.The Team then determines which items they can complete during the coming sprint. Here are some characteristics that differentiate the Product Backlog from any To-Do list:

• All items in the Product Backlog should add value to the customer.
• All items are estimated.
• All items are prioritized and ordered.
• The Product Backlog is a living document.
• The Product Backlog does not contain any low level tasks.

Example Scrum Product Backlog

Only entries that add value to the customer

All items in the Scrum Product Backlog must have add value to the customer. Items without any customer value are pure waste and should not be present anyway. The Scrum Product Backlog can include items for technical options, functional and nonfunctional requirements, bugs, and the work necessary to launch the product.

All entries are estimated

All the entries within the Scrum Product Backlog have to be estimated according to the agreed definition (e.g. story points). This estimation can then be used to prioritize entries in the Scrum Product Backlog and to plan releases, if have a look at the above picture you will find that I have used Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) .

Items in Scrum Product Backlog are prioritized  & ordered

All entries are prioritized and the Product Backlog is ordered. The Product Owner with the help of the Scrum Team does the prioritization. Added Value, Costs and Risks are the most common factors for prioritization. With this prioritization the Product Owner decides what should be done next, I have used the Requirements Prioritization Model created by Karl Wiegers is a more mathematically rigorous method of calculating priority than the other schemes we’ve discussed. Every proposed feature is rated for benefi t, penalty, cost, and risk on a relative scale of 1 (lowest) to 9 (highest). There are several techniques & modles for prioritization such as Kano analysis, MoSCoW prioritization scheme, I will be takling about them in another post soon.

Living document

Living document means that it will change during the project life cycle. If there are new requirements needs to be added, we have to add them, as and the existing requirements may be modified, defined in more detail or even deleted. Requirements are no longer frozen early on. Instead the final set of requirements within the Scrum Product Backlog is also developed iteratively, together with the resulting software.

Different level of details

The requirements in the Scrum Product Backlog have a different granularity. Only those requirements that shall be implemented during one of the next sprints are defined in greater detail and everything else is more coarse-grained. The simple reason for this is that it does not make sense to invest time and effort into the specification of these requirements, as most of these requirements will have changed anyway until implementation starts.

No low level tasks

The Scrum Product Backlog shall not contain the detailed tasks. Basically the final requirements are defined together with the customer during the sprint. Breakdown and distribution of these requirements is the responsibility of the Scrum Team.

SCRUM USER STORIES

Back to top↑

Items in the Scrum Product Backlog are most of the time  written in the form of User Stories. From its name you can tell, what a user story means, it describes & tells a short story about a user that uses the product (System Actor). Mainly it contains three main parts (System Actor, Action, and Achievement). The advantage of user stories is that they focus on exactly what the user needs/wants without going into the details on how to achieve it. There are different recommendations how to define User stories. A template could be as follows: As an [actor], I [want|must] [action] so that [achievement] Or in a shorter version: As an [actor], I [want|must] [achievement].
Actor: The ‘owner’ of the user story. This is often a user but it is recommended to be more specific here. By using specific actors (e.g. “Administrator”, “Logged in Customer”, “Unauthenticated visitor”) it’s easier to understand and sets the user story into context. Action: What the actor want to do. If it is a mandatory action it can be prefixed by “must”. Otherwise “want” is used. Achievement: What the actor wants to achieve by performing the action. This is the result from executing the action seen from the actor’s point of view.

ESTIMATIONS – PLANNING POKER

Back to top↑
All items in Scrum Product Backlog have to be estimated to allow the Product Owner to prioritize the entries and to plan releases.The Scrum Framework itself does not prescribe a single way for the Scrum Teams to estimate their work. However within the Scrum Framework the estimation is not normally done in terms of time – a more abstracted metric to quantify effort is used. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL) or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.). Important is that the team shares a common understanding of the scale it uses, so that every member of the team is comfortable with it.

Planning Poker/ Scrum Poker

Palnning Poker is a technique used during the estimation process it’s also called Scrum Poker. When using Planning Poker, influences between the participants are minimized and therefore a more accurate estimation result is produced. In order to play Planning Poker the following is needed:

• The list of features to be estimated
• Decks of numbered cards.

A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other similar progressions are also possible. The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. A high estimate usually means that the story is not well understood in detail or should be broken down into multiple smaller stories. Smaller stories can be estimated in greater detail. It would be a waste of time to discuss if it is 19, 20 or 25; the story is simply (too) big. The game is then played in the following steps:

• The Product Owner presents the story to be estimated. The Scrum Team asks questions and the Product Owner explains in more detail. If many stories have to be estimated a time-constraint (e.g. only one minute for explanation) might be set as well. If the time-constraint is reached and the Scrum Team does not understand the story it is a sign that the story has to be re-written.
• Each member of the Scrum Team privately chooses the card representing the estimation.
• After everyone has chosen a card, all selections are revealed.
• People with high and low estimates are allowed to explain their estimate.
• Estimation starts again until a consent is found.
• This game is repeated until all stories are estimated.

DEFINITION OF DONE (DoD)

Back to top↑
Definition of Done (DoD) is a shared understanding of what it means when work is considered done, it should be defined at the beginning of the project, and it applies globally to the project. Might include things such as:

• DoD for Unit & functional tests.
• DoD Documentation.
• DoD for a Writing code.

SCRUM BURNDOWN CHART

Back to top↑

The Scrum Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule.

Simple Burndown Chart

The rate of progress of a Scrum Team is called “velocity”. It expresses the amount of e.g. story points completed per iteration. An import rule for calculating the velocity is that only stories that are completed at the end of the iteration are counted. Counting partially finished work (e.g. coding only – test missing) is strictly forbidden. After a few Sprints the velocity of a Scrum Team will most likely be predictable and would allow quite accurate estimation about the time needed until all entries in the Scrum Product Backlog will be completed. If the velocity of a Scrum Team is e.g. 30 story points and the total amount of remaining work is 155, we can predict that we need about 6 Sprints to complete all stories in the Backlog. However in reality the entries in the Scrum Product Backlog will change over the duration of the project. New stories are added and other stories are changed or even deleted. In the simple Burndown Chart the velocity of the Scrum Team and the change in the scope cannot be distinguished. To reflect this, another form of diagram can be used.

Separating Velocity and Scope Changes

Here a bar chart instead of a line diagram is used. The size of each bar represents the total amount of work remaining at the start of each sprint. The velocity of the team is subtracted from the top while changes in the Scope change the bottom of the bar. To get even more accurate we can also take the rate of changes in total work into account. However we have to be careful when using this model since the rate of change will be high in the beginning of the project but will drop at the end.

Extended Burndown Chart with Prediction

In the next post I will be covering Sprints, and Sprint meetings.

References: INTERNATIONAL SCRUM INSTITUTE, You can find a lot of useful information about Scrum and Scrum Certification Programs on thier website.