Search

From Creation To Execution: How Sprint Backlog Helps Scrum Teams

Scrum is an agile way to accomplish the project, usually in software development. In Scrum, artifacts are the key information providers that are designed specifically to enhance transparency of key information required to ensure that the Scrum teams are successful in delivering a ‘Done’ increment. The Scrum Process Framework defines 3 essential artifacts:Product BacklogSprint BacklogProduct IncrementIn this article, we are going to see everything in detail about Sprint Backlog in Scrum. While being a simple concept, it is misunderstood by many people. This article will clear up the confusion and explain clearly what the Sprint Backlog is and how to use it. So, let’s take a look at the ultimate guide of the Scrum Sprint BacklogWhat is a Sprint Backlog?The Sprint Backlog is a set of all the product backlog items chosen for the current sprint, plus a plan for delivering the product increment and achieving the sprint goal. This plan takes the form of all the work required to get the backlog items to “Done” in that sprint.The following video will explain how to create your first sprint backlog.The Sprint Backlog is produced by the team in the Sprint Planning meeting. It is an outcome of that meeting and the Sprint Planning meeting should not conclude until the team has produced the Sprint Backlog in some form (though it can actually change after that, as I’ll explain below). Collated below is the anatomy of Scrum Sprint Backlog.Steps for creating a better Sprint BacklogSprint Backlog is the output of the sprint planning meeting with the participation of every team member in the Scrum team. The process is as follows:There is another final step that many teams don’t do (and don’t know about!). As of the latest version of the Scrum Guide, the team must also add a continuous improvement item to the Sprint Backlog. This is an interesting and important change and will really encourage teams to take continuous improvement seriously (rather than as an afterthought). Make sure you don’t forget to do this with your teams!Once produced, the team should make sure that the Sprint Backlog is visible to everyone. This ties in with the Scrum pillars of transparency, inspection, and adaptation. It provides a clear, real-time view of the progress of the team in completion of the sprint goal and Product Increment.How does the team plan the work?Many people might now be wondering what a “plan” is. The answer is, it can be anything that the team comes up with to complete the product increment and complete the items in the Sprint Backlog. Some people do this by breaking them into tasks, which are estimated in hours. That’s fine, though it’s not mandated by Scrum.Each team should find its own best way to plan and arrange the work. Scrum guide is very clear on this matter:The figure below shows an example of how the development team plans the work to be done in the sprint for each user story.So the Sprint Backlog will start off with some Product Backlog Items. The team can then add tasks, subtasks, designs, diagrams, whatever they like to the Sprint Backlog, as part of coming up with a plan to complete the work.Can you change the Sprint Backlog?Some people believe that the Sprint Backlog cannot be changed during the Sprint, that it is locked down when the sprint starts. This is totally untrue!The Scrum Guide is very clear on this point. It saysThe key point is that only the Development Team can change the Sprint Backlog since it is their artifact. Conversely, the Product Owner owns the Product Backlog and is the only person who can change that.So the team should add, remove, and change things in the Sprint Backlog as the sprint progresses, work is completed, new facts are discovered, and so on.Keep in mind though that the changes should be discussed with the Product Owner (though they don’t need approval from them), and that they should still reflect the team’s understanding of the sprint goal. Changing the Sprint Backlog so that it no longer matches with the sprint goal is a serious decision that would need the agreement of the product owner, and could be grounds for canceling a sprint.Do we have to use tasks?Another myth is that the team must break the stories down into tasks as part of moving them into the Sprint Backlog in Sprint Planning. This is also not true! The Scrum Guide does not include the word “task” anywhere. The team finds its own best way of completing the work.What is the output of a sprint backlog?The output at the end of a sprint is a product increment (PI). A product increment is the sum of all the Sprint Backlog items which are “Done” at the end of the sprint, plus the outputs of all the previous increments in previous sprints.
Rated 4.0/5 based on 1 customer reviews

From Creation To Execution: How Sprint Backlog Helps Scrum Teams

1K
From Creation To Execution: How Sprint Backlog Helps Scrum Teams

Scrum is an agile way to accomplish the project, usually in software development. In Scrum, artifacts are the key information providers that are designed specifically to enhance transparency of key information required to ensure that the Scrum teams are successful in delivering a ‘Done’ increment. The Scrum Process Framework defines 3 essential artifacts:

  • Product Backlog
  • Sprint Backlog
  • Product Increment

In this article, we are going to see everything in detail about Sprint Backlog in Scrum. While being a simple concept, it is misunderstood by many people. This article will clear up the confusion and explain clearly what the Sprint Backlog is and how to use it. So, let’s take a look at the ultimate guide of the Scrum Sprint Backlog

What is a Sprint Backlog?

The Sprint Backlog is a set of all the product backlog items chosen for the current sprint, plus a plan for delivering the product increment and achieving the sprint goal. This plan takes the form of all the work required to get the backlog items to “Done” in that sprint.

The following video will explain how to create your first sprint backlog.

The Sprint Backlog is produced by the team in the Sprint Planning meeting. It is an outcome of that meeting and the Sprint Planning meeting should not conclude until the team has produced the Sprint Backlog in some form (though it can actually change after that, as I’ll explain below). Collated below is the anatomy of Scrum Sprint Backlog.

Steps for creating a better Sprint Backlog

Sprint Backlog is the output of the sprint planning meeting with the participation of every team member in the Scrum team. The process is as follows:

How to create a Sprint Backlog

There is another final step that many teams don’t do (and don’t know about!). As of the latest version of the Scrum Guide, the team must also add a continuous improvement item to the Sprint Backlog. This is an interesting and important change and will really encourage teams to take continuous improvement seriously (rather than as an afterthought). Make sure you don’t forget to do this with your teams!

Once produced, the team should make sure that the Sprint Backlog is visible to everyone. This ties in with the Scrum pillars of transparency, inspection, and adaptation. It provides a clear, real-time view of the progress of the team in completion of the sprint goal and Product Increment.

How does the team plan the work?

Many people might now be wondering what a “plan” is. The answer is, it can be anything that the team comes up with to complete the product increment and complete the items in the Sprint Backlog. Some people do this by breaking them into tasks, which are estimated in hours. That’s fine, though it’s not mandated by Scrum.

Each team should find its own best way to plan and arrange the work. Scrum guide is very clear on this matter:

Team Plan Work Quotation

The figure below shows an example of how the development team plans the work to be done in the sprint for each user story.
how the development team plan the work to be done

So the Sprint Backlog will start off with some Product Backlog Items. The team can then add tasks, subtasks, designs, diagrams, whatever they like to the Sprint Backlog, as part of coming up with a plan to complete the work.

Can you change the Sprint Backlog?

Some people believe that the Sprint Backlog cannot be changed during the Sprint, that it is locked down when the sprint starts. This is totally untrue!

The Scrum Guide is very clear on this point. It says

Sprint backlog quotes

The key point is that only the Development Team can change the Sprint Backlog since it is their artifact. Conversely, the Product Owner owns the Product Backlog and is the only person who can change that.

Adding new required tasks to the sprint backlog

So the team should add, remove, and change things in the Sprint Backlog as the sprint progresses, work is completed, new facts are discovered, and so on.

Keep in mind though that the changes should be discussed with the Product Owner (though they don’t need approval from them), and that they should still reflect the team’s understanding of the sprint goal. Changing the Sprint Backlog so that it no longer matches with the sprint goal is a serious decision that would need the agreement of the product owner, and could be grounds for canceling a sprint.

Do we have to use tasks?
Another myth is that the team must break the stories down into tasks as part of moving them into the Sprint Backlog in Sprint Planning. This is also not true! The Scrum Guide does not include the word “task” anywhere. The team finds its own best way of completing the work.

What is the output of a sprint backlog?
The output at the end of a sprint is a product increment (PI). A product increment is the sum of all the Sprint Backlog items which are “Done” at the end of the sprint, plus the outputs of all the previous increments in previous sprints.

Leon

Leon Tranter

Blog Author

Leon Tranter has 13 years' experience in Information Technology and is passionate about Agile, Scrum, Lean and Kanban. He is a Certified Scrum Master, LeSS Practitioner, and coach in the XSCALE Alliance.“He writes about Agile, Scrum and Lean at Extreme Uncertainty

Join the Discussion

Your email address will not be published. Required fields are marked *

1 comments

Sanjeev 04 Aug 2018

Nice read..

Suggested Blogs

How Does an Agile Mindset Pave the Way for Professional Success?

In the days before the advent of Agile, most large organizations were run with a bureaucratic mindset. Even as Agile has taken over the world of work today, a large number of professionals and organizations are yet to embrace the Agile mindset as they are stuck in the traditional paradigm.  Traditionally, the primary focus of managers in a top-down hierarchy has been on bringing in funds for the organization and its investors, even as they are sorting out work in line with the rules, jobs, and criteria that have been pre-determined. The existence of a bureaucratic mindset, therefore, promotes hierarchy over collaboration. When the workforce has a bureaucratic attitude, the productivity at an organizational level gets impeded. This is especially the case in situations that are subject to rapid changes concerning business needs,opportunities, or challenges.. What is an Agile mindset? An Agile mindset is a mentality of having a positive, feedback-based,and flexible perspective. This mindset places high regard on mutual respect, collaboration, improvement, iterative construction, and learning cycles. It takes pride in ownership, lays focus on delivering value, and has the inherent ability to adapt to change. An agile mindset is critical to cultivating high-performing teams, capable of delivering amazing value for their customers. The Characteristic Traits of An Agile Mindset An agile mindset can be identified by certain behavioral traits. These are applicable at the level of an individual, team, and enterprise at large.  High degree of collaborative efforts: Teamwork is crucial to foster an Agile mindset. Those who wish to cultivate this mindset should have a thorough understanding of objectives, deliverables, and ownership. Tolerance, mutual respect, and a team-player’s attitude are essential for effective collaboration. Self-motivated: A certain sense of motivation will be displayed by professionals having this mindset. They are often driven enough to execute tasks until completion and even develop better strategies to perform tasks. Self-motivated teams are empowered teams as they are capable of driving success with their efforts while taking responsibility for their actions at the same time. Customer-focused and outcome-driven: Delivering value to customers within the stipulated deadlines and budget is second nature to those with an Agile mindset. Customer’s needs are top priority and an outcome-based approach will be followed to meet them.Speed and Transparency: A quick turnaround time is a hallmark of Agile environments. Work is often done in small increments over time while the feedback loops are shortened to boost progress and reduce errors. Transparency is a trait that every member of the team should possess so that work can be entrusted to them without a second thought. Getting Ahead with An Agile Mindset  A significant aspect of having an Agile mindset is an individual’s willingness to remain unfazed in failure, yet open to learning and growing to prevent the same mistakes. As a professional in the dynamic digital age, one has no option but to embrace changes.  With new technologies, work processes and customer demands emerging daily, cultivating an Agile mindset has become imperative for professional growth. Farsighted organizations have already embarked on their Agile journeys, with 92% senior executives globally believing that organizational agility is critical to business success.  This calls for the need of an Agile workforce and translates into greater opportunities for skilled professionals with an Agile mindset. The true adoption of the Agile mindset cannot happen over-night, it takes a gradual shift in perspectives which will eventually guarantee lasting returns. Attending workshops led by Agile experts is a great way to get started with one’s journey towards developing an Agile mindset. Not only will it help shape one’s mindset but also open doors to exciting opportunities in Agile. 
Rated 4.5/5 based on 0 customer reviews
How Does an Agile Mindset Pave the Way for Profess...

In the days before the advent of Agile, most large... Read More

Four Ways to Agile Your Tech Team

Agile organizations fared substantially better than their non-agile counterparts in performance metrics as per research from the Project Management Institute. For example: 75% their goals compared to 56% of non-agile organizations 65% finished projects on time compared to 40% of non-agile organizations 67% finished projects on budget compared to 45% of non-agile organizations Revenue grew 37% faster Agile organizations generated 30% more profits    Clearly, there are benefits to using agile methods, and tech teams, in particular, can benefit from this project management approach. Here’s how you can train your team on the Agile methodology. 1. Use the Agile Manifesto The first step of becoming agile is introducing your team to the Agile Manifesto. A total of 12 principles make up its core. You can teach the principles through exercises and assignments.The emphasis of these exercises is self-discovery rather than just teaching. For example, begin with asking your team about the manifesto. Let them discuss the principles with each other. Then, hold a brainstorming session with your team to list the principles that will be effective in group discussions. You can then give them a written assignment to apply principles to their current software development styles. The aim of these assignments is to adopt and memorize the principles. One great way to teach the basics—especially for new tech teams—is to create a simple fill-in-the-blanks exercise. 2. Live training rather than theoryThe Agile methodology is best learned through real life examples. There are different applications of agile, like Scrum, XP, Crystal, and Kanban, which your team may be familiar with, but it is still useful to go through examples. Live training is suitable for intermediates and experts in Agile methodology. Follow the steps below to help your tech team learn agile in live examples: Start a project based on your current methodology, like Scrum or XP Define the scope and goals of the project Design guidelines for project requirements Develop a software function Integrate the function with the agile methods Test the function If the test is successful, move to next function and repeat steps 4-6 Record errors if the test is unsuccessful and include changes until the function works Reprioritize project objectives based on client feedback Release the function to the market, once you incorporate feedback Move on to the next product and repeat steps 4-10 until the project is complete One of the best ways to implement Agile is to have your team members complete online course certifications.  3. “We,” not “I” Collaboration needs to be at the core of the agile implementation for the process to work properly. This is because the key stakeholders of the agile method are the customer and cross-functional teams. There needs to be proper communication and inclusion so that they can provide proper iterations to make the final product.  During training, emphasize collaborative frameworks. Include customer use cases in live training to highlight how customers can collaborate on the final product. You should focus on creating a collaborative and user-focused environment. The first step is to reorganize your team dynamics to create opportunities for collaboration. Have your tech team members work together in pairs, programming, and peer testing. 4. Hire an Agile CoachBefore hiring an agile coach, it is important to know your budget and your timeline. Coordinate live projects your tech team is working on using agile methods. An agile coach should use live examples from existing projects to make training more relevant for your team. There are two styles of agile coaching: push-based and pull-based. Pull-based coaching subconsciously engages team members to adapt principles and values by giving consistent, encouraging feedback. This method facilitates learning with minimal involvement of the coach. Push-based coaching technique is when the coach plays a direct role in imparting knowledge. More on teaching the Agile Methodology When adopting agile project management, managers should emphasize collaboration and customer engagement. They should focus on work fluidity and teamwork, on the “we” and not the “I” mentality. If properly implemented, this dynamic project management method can realize great results for a tech team. If you get it right, you stand to boast, happier, healthier, and more engaged employees overall.
Rated 4.5/5 based on 45 customer reviews
15795
Four Ways to Agile Your Tech Team

Agile organizations fared substantially better tha... Read More

The Remote Retrospective with a Distributed Team

In this article, some of our Agile experts dives into organizing a remote Retrospective with a distributed team. They share some of their practices, tools, and lessons learned. The Scrum Guide on the Sprint RetrospectiveAccording to the Scrum Guide, the Sprint Retrospective serves the following purpose: The purpose of the Sprint Retrospective is to: Inspect how the last Sprint went with regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work.The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation. Source: The Scrum Guide 2017 This purpose is a compelling pitch as it addresses the why, the what, and the how of the Retrospective. There is no reason to deviate from this guideline just because we are working in a remote setting. Virtual Liberating Structures and Breakout RoomsBelow are a few suggestions on handling a remote Retrospective as the host, facilitator, or Scrum Master. For this: a) we use Zoom as a video application as we need to work in breakout rooms, and b) our Retrospectives are modeled around Liberating Structures strings. We usemany other techniques from the agile toolbox too (plenty are available on Retromat or Tasty Cupcakes). Design Elements of Virtual Liberating StructuresVirtual Liberating Structures share a set of common design principles: Breakout rooms: The whole group of participants is divided into smaller workgroups, starting with pairing up two participants. Muting/unmuting: Beyond just reducing noise, this helps to mark different states of participants. Video on/off: Used to distinguish between roles, for instance, between the inner circle and the outer circle of the User Experience fishbowl. Here, the outer circle members turn their video off as well as mute themselves. A shared workspace: This is needed to aggregate findings, for instance, as the result of a 1-2-4-All session. This can be a simple Google slide or a FunRetro.io board. Workbooks: These are useful to provide participants with instructions when working in breakout rooms; for example, a detailed description of how an individual Liberating Structures works. A chat channel: This is used to facilitate communication within the whole group.The Five Stages of a Retrospective The following LS microstructures refer to these basic patterns of virtual Liberating Structures. This design has been modelled after Esther Derby and Diana Larsen’s five stages elaborated in their book, Agile Retrospectives. I. Setting the Stage Impromptu Networking is a simple application of breakout rooms; just make sure that after each round, the pairs are created a new. Provide the invitation and the three questions in the workbook in advance.  Organizing a Mad Tea in the virtual realm requires a different approach. Of course, we cannot recreate two concentric circles of attendees facing each other. However, what we can do is use the prompts—the half-sentences that the attendees shall complete—and the chat channel to create a quick and comprehensive picture of the team’s sentiment.  Use check-ins with emojis and choose from a growing list of online icebreakers. Consider crafting a working agreement for the upcoming meeting or workshop if the team has yet to do so. II. Gathering DataThere are numerous ways of gathering data for an upcoming Retrospective. Probably, you want to track quantitative metrics like cycle-time or the number of bugs that escaped to production. Or you might be interested in qualitative metrics such as team-health or the sentiment of the team members. The point is that concerning the data, it does not matter whether the Scrum team runs the analysis in a face-to-face or remote setting: Both environments provide access to the same data. Typical practices of gathering data for Retrospectives are: Not only is Impromptu Networking an excellent way to create a sense of togetherness among the participants, but it is also a useful exercise to gather data if the invitation is crafted in the right way. Anonymous surveys provide an option to collect data during the Retrospective as well as in advance. Those surveys can be Sprint-specific, pencilled-in between the Sprint Review and the Retrospective. Alternatively, they can be open-ended surveys such as a permanent suggestion box. Or, they are conducted at regular intervals to track progress in areas of interest. Suitable applications for this purpose are, for example, Google Forms, Typeform, or SurveyMonkey. A subset of the anonymous survey is the ‘Team Radar.’ It is a great way to create transparency about important team matters and track their development as time passes.  Finally, you can derive metrics from supportive applications, for example, your ticket system.III. Generate Insight from the DataIII. Generate Insight from the Data After collecting the data, the task ahead is to make sense of it. The following three LS microstructures have proven to be useful, also in a remote setting:  What, So What, Now What? is a sequence of individual work and group work based on breakout rooms, aggregating findings in shared workspaces to be shared with the whole group in the end.  Again, TRIZ is a combination of basic elements of virtual Liberating Structures: breakout rooms, embedded 1-2-4-All, joined workspaces, Shift & Share when several groups are working on the problem. Consider time-keeping via the breakout room broadcasting function, as participants are likely to be highly engaged and may lose track of time.  Use the Conversation Café by creating groups with the breakout room function, and identify a host for time-keeping. During rounds 1, 2, and 4, where one participant is talking while the others are listening, use mute for the listeners. Once the timebox has expired, the previously talking participant “hands over” the microphone by calling out the next one in line and then muting him- or herself. As the facilitator, also consider providing a matrix — rounds by speakers with checkboxes — to the hosts to ensure that everyone has a fair share of airtime.) IV. Deciding What to DoThe next step of the remote Retrospective is to agree on improvement items that will allow the team to grow and become more mature. Four Liberating Structures microstructures well-suited for this purpose: 15% Solutions: We use a similar procedure as with TRIZ. Consider aggregating all suggestions in the whole group’s shared workspace for clustering and ranking by voting. TheFunRetro.io board is simple and does not need much explaining. 25/10 Crowd Sourcing: This microstructure belongs to those that are hard to replicate online with the currently available tools. You can use a form application to collect both suggestions from the team members on the subject in questions as well as their names. Once all participants have filled out the form, export the answers as a CSV-file and import this file into a FunRetro.io board. As the facilitator, distribute the answers in packs of five to new columns and allocate the “name tags” of the participants randomly to each column in an even distribution. Then activate the voting and ask all participants to vote on the answers in the column they have been assigned to before. Set the number of available votes so high that every answer in a column can be awarded from 1 to 5 votes. Once the voting has ended, move all answers to one column and activate the “vote count.” Finally, sort that column by votes. While there are many issues with this process, it tends to point in the right direction. Lean Coffee is an excellent example of a workaround for virtual Liberating Structures. Gather all the input in the usual way, for example, engaging in 1-2-4-All, and gather those on a FunRetro.io board while voting is turned off. (Use several columns if the whole group is large to speed up the gathering process.) Then ask the whole group to cluster similar topics, then turn on the voting and order the remaining entries by votes. For here, you continue with a whole group discussion, or you engage smaller groups with breakout rooms.  Ecocycle Planning: Principally, we apply the techniques as before, from breakout rooms to shared workspaces. Speaking of which, given the large number of “stickies” that you usually create during Ecocycle planning, you may want to consider a specialized online board application such as Miro or Mural. V. Closing the RetrospectiveThe last step of the Retrospective sequence is the closing or check-out. Basically, it is a mini-retrospective within the “large” remote Retrospective focused on reflecting on what has happened as well as providing feedback: Was the time well-spent or do we need to change our approach to running a remote Retrospective next time? Although we do not pass a door while leaving the meeting room, there are many ways to collecting the feedback of the team members: We can replicate the door sticky practice with the annotation tool of the video application on a prepared graphic. All at once, attendees leave a symbol on a scaleThen some applications allow for gathering live feedback, such as Poll Everywhere. Alternatively, run a Fist of Five voting.Good Practices for a Remote RetrospectiveFrom the list of all practices that generally apply to remote agile events, there are three practices that make hosting significantly easier: Create a script with the probable timeline of the remote Retrospective in advance, including all the required documents to be shared with the participants and all the copy you need to provide to the chat during the session. Document the outcome of the remote Retrospective so team members can revisit them at a later stage. Restrict access to sensitive information by limiting access privileges strictly to team members. Keep good track of action items. Without a prominent placement in the team room, improvement items tend to be forgotten. Antipatterns of Remote Agile RetrospectivesThere are plenty of Retrospective anti-patterns in general. But a few anti-patterns of Scrum Masters are particularly relevant for a remote Retrospective: Waste of time: The Retrospective provides a poor return on investment.   Prisoners: Some team members only participate because they are forced to join No psychological safety/bullying: A few participants dominate the Retrospective, while the more introverted team members pull back, and the host/Scrum Master does confront this misbehaviour. Groundhog day: A useful routine has been turned into a mindless ritual. If you run the same-style Retrospective format over and over again, do not be surprised if the team is no longer improving its way of working, and the mood is turning sour. The problem for the host is that this effect happens in a remote setting significantly faster by comparison to a face-to-face Retrospective. Remote Agile speeds up the revelation of collaboration issues.Conclusions Working as a distributed agile team is, in many aspects, more difficult than being co-located: ‘Reading the room’ is significantly more complicated, for instance, and communication is taking a toll as the beloved informal meeting at the coffee machine is no longer happening. However, being suddenly distributed does not mean that we cannot have useful critical events anymore. On the contrary: the necessity to invest more preparatory work upfront may provide a chance to improving the meaning of events.
Rated 4.5/5 based on 45 customer reviews
18709
The Remote Retrospective with a Distributed Team

In this article, some of our Agile experts dives i... Read More

Useful links