SKILLS & TRICKS
Scrum ArtifactsScrum Artifacts – results/products of our management activities – are designed to increase transparency of information related to the delivery of the project, and provide opportunities for inspection and adaptation. There are six artifacts in Scrum:
Items 5 and 6 might look more like activities, but they are considered artifacts in the Scrum Guide, and therefore we will explain them as so. You can imagine their output (tracking information, burn-down charts, etc.) as the real artifacts and these two items as ongoing activities (like Product Backlog grooming) or part of the Scrum events (part of Sprint Review and Daily Scrum). 1. Product Backlog
The Product Owner sets a number of factors to determine the value of each item for the business. Return on investment is usually one of the factors. All these factors will be summarized into one value (importance) and this is shown with each item. The Product Backlog items will then be ordered based on their value, in a way that the higher an item is, the sooner it will be delivered by the Development Team. As the items located at top of the Product Backlog will be delivered sooner, they will also be more detailed and clear compared to the lower items. The next figure shows a sample set of Product Backlog items presented in a number of cards. The Product Backlog is an ordered list of items (stories) Each Product Backlog item also has a work estimate. These estimates are solely done by the Development Team, and are used in comparison to the capacity of the Development Team in a single Sprint, to determine the number of items that will be selected for that certain Sprint. Additional information might be added to each item to help the Scrum Team take control. This figure shows the type of information available for a single Product Backlog item in a typical Scrum tool. This is also a good example of a Scrum tool. Take your time to study this diagram as it contains a lot of information. These are the different parts of this dialog box:
One important use of Scrum tools is collaboration. Collaboration features are more important when the Scrum Team is not co-located and traditional ways of collaboration are not possible. The following figure shows a sample Product Backlog created in an online Scrum tool. The Product Owner has identified the stories, but the estimates are not done yet (question marks on the right side of the rows). Current status of the sample:
The Scrum Team should add details, estimates, and order to the Product Backlog items all the way through the project, which is called Product Backlog grooming. It should not consume more than 10% of the time of the Development Team. The Product Backlog is created more based on discussion rather than documentation. The Product Backlog items (aka stories) should be easy to understand for non-technical stakeholders. The following figure shows the sample Scrum tool after the addition of the estimates. Current status of the sample:
The total amount of work in this sample is shown to be 234 points. It is common to break the large stories (such as the tenth story in the sample which is estimated 100 points) into two or more stories later. Sometimes multiple Scrum Teams work on the same project. The Product Backlog is a representation of the scope of the final product and therefore, there should be only one Product Backlog, no matter how many Scrum Teams are working on the project. 2. Sprint BacklogThe Sprint Backlog is created during the Sprint Planning event which is the first event in a sprint. During the Sprint Planning event, the Scrum Team collaborates on creating the Sprint Backlog, which consists of the following:
The Sprint Backlog is frozen after the Sprint Planning and the Development Team will focus on delivering an Increment of “Done” based on this plan. The statement “the Sprint Backlog is frozen” means that items (stories) in the Sprint Backlog cannot be added or removed during the Sprint. However, it might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner. The detailed plan which is normally not complete at the end of the Sprint Planning will become more complete as the Sprint continues. The following figure shows the sample project in Sprint Planning time: a new Sprint, called “The First Sprint” is defined with start and end dates, and Scrum Team are now ready to select items from the top of the Product Backlog to be assigned to this Sprint. Current status of the sample:
Suppose that the estimated capacity of the Sprints is 50 points. In this case, all we can choose for the Sprint is shown in the next figure. Current status of the sample:
Now we have four items with an estimate of 44 points. We cannot add the next Product Backlog item, because it has 40 points and we only have about 6 points free in our Sprint capacity. It is common for the Product Owner in such cases to reorder the backlog; for example to bring The Sixth Sample Story above The Fifth Sample Story, and so we can add it to the Sprint Backlog (next figure). Current status of the sample:
The next figure shows the Sprint items, along with a summary, and a burn-down chart. Current status of the sample:
This screen acts like a dashboard and we can use it to plan and track the items. In the next figure for example, some of the items from the top of the list are broken down into tasks. Most Scrum tools are equipped with collaborative features, which are especially useful for remote teams (adding comments and sharing ideas for example). Current status of the sample:
As we go through the Sprint, some tasks and items get Done and more items are detailed. Current status of the sample:
The Scrum tools usually update the burn-down chart as we progress through the Sprint. 3. IncrementAn Increment is a sum of all completed Product Backlog items at the end of a Sprint. Each Increment must be “Done”, and must be releasable. The Product Owner may or may not release a certain Increment, but it should be releasable (shippable). The next figure shows how the number of stories in the Product Backlog decreases Sprint by Sprint, as the number of features in the Increments increases. Note that the Increment concept is cumulative: each Increment also contains the features of the previous ones. 4. Definition of DoneThere should be a shared understanding of what it means for a piece of work to be “Done”. This definition of “Done” must be discussed and agreed upon by the Scrum Team at the beginning of the project so that future Increments would be releasable. When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of “Done” for all teams, because they might be working on items of different natures. In such a case, each Scrum Team will define its own definition of “Done” and delivers its items based on that definition. However, the integration of those definitions of “Done” should be capable of creating a potentially releasable Increment in the project level. 5. Monitoring Progress Towards a GoalUp to now, we have used the burn-down chart to visualize the progress of development during a Sprint. You can also use a burn-down chart to visualize the progress of the whole project and this is called the project burn-down chart. The Product Owner is responsible to monitor the progress of the whole project toward its goal. This should be done at least once per Sprint Review. The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints, and forecasts the completion date of the project. All stakeholders should have access to this information. The project burn-down chart shows the amount of remaining work, instead of the amount of completed work; therefore, the line for actual performance goes downward as we proceed and the faster it goes down, the happier we will be! The vertical axis (remaining work) shows the amount of work (which is a sum of all the estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time passed from the beginning of the project or the number of Sprints passed. We usually add another line to present the uniform distribution of the volume of the work across the initially estimated number of sprints. This line acts as our planned progress, and will be used to compare to our actual values. In the above chart, we can expect the project to be completed earlier than initially planned. 6. Monitoring Sprint ProgressBesides the monitoring done for the whole project, we should also monitor the progress of each single Sprint throughout its life. This is the responsibility of the Development Team and should be done at least once per Daily Scrum. This information is used to calculate the likelihood of achieving the Sprint Goal and completing all items of the Sprint Backlog. The Sprint progress information can be represented by a burn-down chart, and this chart can be a part of the Sprint board, where everyone can see.
0 Comments
Leave a Reply. |
Archives
February 2020
Categories
All
|