Kickstart your career with best deals on top training courses NY10 Click to Copy

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.
From Creation To Execution: How Sprint Backlog Helps Scrum Teams
Leon
Rated 4.0/5 based on 1 customer reviews
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

Posts by Leon Tranter

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 Hel...

Scrum is an agile way to accomplish the project, u... Read More

The Evolution Of Kanban: A Study Of The Principles & Practices

As a part of the overall move towards Agile software development and related disciplines, many people are interested in Kanban. Some are applying it as a part of Agile, others are looking into it as an alternative to Scrum. There is a lot of confusion about this simple yet effective tool, so this article will clear up these misconceptions and provide a quick crash course into the essentials of Kanban. Where did Kanban come from? Kanban originated in Japan in the 1940s. People from the Toyota car manufacturer noticed that supermarkets used a simple but effective system based around small physical cards to indicate when something was out of supply or needed to be ordered. They applied this system in their own manufacturing process to help visualise work and control flow. Kanban became a part of Lean Thinking and the Toyota Production System. It was later popularised amongst software developers in 2010 by David Anderson with his book “Kanban: successful evolutionary change for your business”. What really is Kanban? Kanban is a simple but powerful system for visualising and managing work. It is not just related to software development, in fact, it is not specifically related to development of any kind. It can be used in a restaurant, a supermarket or a car factory. It has four principles and five practices. As opposed to Scrum, which involves revolutionary change, Kanban is about evolutionary change, starting from right where you are now (in fact, that is one of the fundamental principles: start off by changing nothing whatsoever! You won’t find any organisation on earth that will resist that change). It is fundamentally about visualising work and then finding ways to improve the flow of work through a system.   Nice visualization of the Kanban principles and practices pic.twitter.com/WbDMSoRfk5 — maciej sowiński (@maciej_sowinski) January 13, 2016 The Four Principles of Kanban This section will discuss the four fundamental principles behind Kanban. They are all essential to understanding and implementing the practices. Fortunately, they are simple and can fit into any organisation or system. Start with what you do now As mentioned, Kanban is a method for gradually improving an existing workflow or system. So you start with whatever you are doing now - whether simple or complex, big or small. You can use Kanban alongside or on top of any existing framework or system you are using - Scrum, Waterfall (yes Waterfall!), or anything, really. Many people believe they have to choose between Scrum or Kanban - untrue! You can use them together. Agree to pursue incremental, evolutionary change As opposed to systems like Scrum or Extreme Programming, that start out by fundamentally changing the structure and behaviour of organisations, Kanban is about evolutionary change, one small increment at a time. This can make it well-suited to cumbersome organisations that resist large risky changes. Respect the current roles, responsibilities, and titles Kanban doesn’t start off by renaming people or inventing strange new roles. Everyone gets to keep not only their job but their job title too. This further helps resistance to change. Encourage acts of leadership at all levels This is a subtle but very important principle. Improvement is the responsibility of everyone in the organisation, from the CEO down to the receptionist. You might get to keep your current job title and responsibilities, but you also now have an additional responsibility: leadership, which is really about empowerment and improvement. The Five Practices of Kanban Unlike Agile, which only has values and principles, Kanban has actual practices that you can employ, starting from day one. Visualise the workflow This is the most important step in all of Kanban, and is at the core of the whole system: visualising work. This was trivially easy to do in Toyota car manufacturing plants: the work was cars lying around in various states of semi-construction. For knowledge work like software development, marketing or design, it is much harder to visualise. This can let work accumulate and create huge blockages without anyone being aware. So visualise the work! This will make it easy to see where work is piling up and where problems and bottlenecks are. The best way to do this is on a physical board, using tokens such as index cards or post-it notes. Putting the work in an electronic tool might seem convenient but when the computer is switched off or minimised, the visualisation of the work is gone. The bigger and more physical, the better! You want to aim for information radiators (that push information out to the organisation) rather than information refrigerators (that preserve information away from people’s eyes). The most common way to visualise the work is with a Kanban board that has vertical swimlanes to represent states of work. You can then place cards on the board to represent the actual work item. Here is an example of the simplest of Kanban boards, with lanes for To Do, Doing and Done: Here is another example of a board, this time with some extra lanes, numbers that indicate Work in Progress Limits, and cards marked as being Blocked. Limit WIP Limiting WIP (WIP stands for Work In Progress) is another key practice of Kanban. People often think that we want to maximise work in progress - that means everybody is busy and lots is getting done, right? Well, if you have lots of WIP, then everyone will probably be very busy, but that isn’t really valuable. We want work in a Done state, not in a “Doing” state. And the best way to ensure that is to actually REDUCE the amount of Work in Progress! It might sound counterintuitive, but it is true. Lots of WIP means lots of handoffs, queues, bottlenecks and task-switching. This all means not much getting actually Done. Minimising WIP means you can maximise flow, which maximises the amount of work Done. And that’s the true goal. Manage Flow Kanban focuses on reducing WIP in order to maximise flow. If you want lots of work to get to Done but don’t want lots of work in a Doing state, you have to reduce the amount of time it takes for work to go from Doing to Done. This is called Cycle Time. Kanban practitioners have many tools they can use to improve flow and reduce cycle time, and these will often become clear after you have visualised the work. They include eliminating approvals and handoffs, swarming on complex slow tasks, identifying bottlenecks, putting WIP limits on Kanban lanes, reducing wait time between tasks, and reducing queues. Make Process Policies Explicit As you implement new rules and policies to improve flow, ensure you make these explicit. If you have a Definition of Done, get people to agree to it and publish it. If you change the rules about approving a document, make sure this is understood and explicitly described. Improvements will fall away and get misused if they are not clearly articulated and understood. Improve Collaboratively, Evolve Experimentally Improving is a collaborative team effort, not something randomly forced on people by some arbitrary management edict. It should be implemented by teams in an iterative experimental effort. Teams need to feel they are in an environment where experimentation is encouraged and it is “safe to fail”, or nobody will try making genuine changes. I hope you have enjoyed this crash course in Kanban - many people are using this system to great effect. If you want to know more, I would recommend the books Kanban by David Anderson, or Kanban in Action by Joakim Sunden and Marcus Hammarberg.  
Rated 3.5/5 based on 4 customer reviews
The Evolution Of Kanban: A Study Of The Principles...

As a part of the overall move towards Agile softwa... Read More