Learn Software Development » Sprint Backlog

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Thu, 02 Dec 2010 18:28:39 +0000

In the previous post, we talked about about the dependencies and design issues (improving the Velocity of your Scrum team) that can impact the efficiency of the Scrum team and how to monitor them to improve them. In this post, we will talk about these and some more factors that need to be monitored to improve the efficiency of the Scrum team.
- In the previous post, I had talked about the dependencies that come out of the dependencies between the teams. I wanted to talk more about such dependencies and the complications that can come out of such dependencies. Consider the case of multiple teams that have complex dependencies between each other and which follow the Scrum model.
So, consider the case of a team that depends on another team for some components. Both these teams follow the Scrum model of development, and plan for each Sprint at a time. This is something that I experienced when we working for a project. We had talked to another team for some components in advance of when we needed these components for a future Sprint feature. However, given that the other team was also doing a Sprint planning, these requests went into their own Sprint planning backlog for prioritization by their Product Owner.
The other team was a supplier of components to many product teams, and as a result, our request was balanced against their other priorities and was not considered important enough for the current backlog. Further, since the team only did selection of tasks for the forthcoming Sprint, it was hard for them to commit as to when they would be able to support our needs. And, given that our request was a bit complicated and different from their other requests (from other teams), they were unable to do an easy estimation of the time that would be required to implement unless the request went through the whole process of Sprint Planning, explanation, and estimation of the tasks that went into doing the User Story.
So, the net result was that we we had a feature that was fairly important for our product, but in the overall scale of importance for the organization, there were other teams that were more important and hence we did not have a commitment for when the dependencies would be resolved. And the problem was, this was as per the Scrum process. So, what was the solution. One way would be for the other team to be able to spend the required amount of time of analysis and commit in advance of the Sprint (by tasking a User Story for the breakdown of the request and estimation) and, further, do some scheduling of these User Stories for the forthcoming Sprint outside of the regular cycle of Sprint planning.
And this was exactly what we did, through working with the Product Owner and other managers of the team, and seemed to realize that this was not a good way of resolving the dependency, but we really did not have a good solution. If somebody has some better ways of working out such dependencies, then please do put these in the comments.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Mon, 29 Nov 2010 18:53:42 +0000

This is another post in a series of posts that talk about how to improve the Velocity of the team (read the last post on the same topic). In this post, I will mention a few points that can be focused on in terms of how to improve the Velocity of the team:
- Ensure that the backlog is maintained properly and visible to all the team members (and this includes both the Product Backlog and the Sprint Backlog). Ensuring that the Product Owner is keeping the Product Backlog updated with the backlog items ordered by priority (and putting this list up on walls and other places close to the team) ensures that the team is forever aware of the set of features that are going to come up in the future, and can already start thinking about some of those features (even if they do not actually start working on those features). Similarly, the Sprint Backlog needs to be regularly updated (the Sprint Backlog provides details of the tasks for a Sprint, including the tasks that are meant to be completed in the Sprint).
- Check out the team sizing. The recommended team size for a Scrum is between 5 to 9 members. If you setup Scrum teams that are more than these in terms of size, there are issues in terms of logistics. The Daily Scrum meeting gets more people, is more than just 15 minutes for the entire team, and gets people starting to feel that too much extraneous stuff happens in the meeting and maybe not worth attending. I have seen such things starting to happen, and seen how the communication process in teams (so critical to Scrum) start to become more difficult, with impacts on the functionality of the Scrum teams. Make sure that there is constant feedback from the team as to whether they are finding the Daily Scrum meetings useful, and worthwhile for them.
- Get advance planning done for the various features that are done as part of the Sprint backlog. For many features which are more complex, before the work can start for the engineering estimation and breakup, there needs to be some amount of discussion on what shape the feature can take. This is even more important when the features are complex or new, and there is no precedent of the features in other products (competitor products); in such cases the user story is not so easy to define. There needs to be pre-work done in advance so that enough of the design of the feature is done. What this typically means is that, in the Sprint before the feature is supposed to be detailed in User Stories, the User Design Specialists and the Product Owner need to spent some time preparing design, and if necessary, working with some elements of the engineering team to do prototyping and work through the architecture. This gives insight into some possible approaches in which the team can work; in a lot of cases, this advance work ensures that the team goes off in the right direction when it comes to actually breaking up the User Stories into tasks.

How does the Scrum team decrease the difference between Capacity and Velocity (contd..) ?

ashish — Tue, 09 Nov 2010 18:06:39 +0000

For the past couple of posts, we have been writing posts that talk about the Capacity and Velocity of Scrum teams, and have started focusing on how to increase the Velocity of Scrum teams, as well as some of the problems that cause a reduction of the Velocity of Scrum teams. In the previous post (Scrum team and Velocity), I talked about some problems such as Communication problems, Stress, the distraction caused due to Social Networks, etc. In this post, I will talk about more issues that impact the Velocity of a Scrum team.
- Proper measurement. For a team to determine their Velocity, it is pretty important that they make sure that all the measurements that are required to determine their Velocity are done. This cannot happen just like that, instead it is required that the team have a proper plan for the measurement of the velocity of the team.
- Define the various impediments that could be preventing the team from being able to improve their efficiency. For example, there might be problems that are preventing integration of components, or dependencies, or technical issues, and these cause problems in terms of reducing the efficiency of work. As an example, if a team member has a hardware issue or some software problems, not resolving them in time can cause some time off.
- Scheduling of tasks. A Scrum team typically consists of Dev and QE team members. In such a team, there is a high degree of probability that the work scheduling will result in the QE waiting for Dev to complete their work and hand over developed code for testing. This results in wastage of time of the QE members, and there is a need to ensure that work is scheduled in such a way that there is work for QE members right from the beginning (and this could include work such as preparation of test cases, or the like)
- There are organizational issues that could also cause problems in terms of impact on the velocity of the team. Some of these issues are related to team members of the team who are uncomfortable with Scrum, or who are not convinced of the benefits and the process to be followed in Scrum, or related matters.
- Requirements being modified during the course of the Sprint cycle. In the Scrum process, there is flexibility to be able to take new requirements, but the assumption is that in the middle of the Sprint cycle, the requirements as defined at the beginning of the Sprint cycle hold good and will not be changed during the course of the Sprint cycle.
- A high level of maintenance work during the course of the cycle. In a number of teams that I have seen, the effort needed to provide ongoing maintenance is really not accounted for during the course of the Sprint cycle, and hence the effort does not go towards the calculation of Velocity, resulting in a reduced velocity during the course of the Sprint cycle.

Delivering to multiple clients – need to deliver through the Sprint rather than one deliverable at the end

ashish — Sun, 03 Oct 2010 18:43:32 +0000

We all learn things as we see stuff happening, and one of the items that I learnt was about a team that had changed to using the Scrum model of development, and was learning how to deal with multiple clients. Consider the case of large software companies such as Microsoft, Apple, and many others, where there are many different groups working on different products. However, the products that they are working on have many common needs, such as code for showing UI, code for handling calls to various media items such as disk drives, CD devices, cameras, etc. It does not make sense for separate teams to write their own code for such handling, and hence it is far more feasible for there to be a single team that works on developing these technologies, and the output of these common teams is used by the various product teams.
One of the biggest problems faced by such common teams (or we can call them technology teams) is their need to match their output schedule to the schedules of the various product teams, and this is something that remains in flux. Different products have their own schedules (with these typically not being very flexible, since there could be the need to meet a specific timeline such as having a new version of the product ready for Christmas, or to be available to meet the perception of financial analysts, or to thwart the release of a competitive product, and so on). So, the common situation is that when the technology team starts interactions with the various product teams (and we can call them the client teams), they are presented with schedules that do not seem to easily integrate with each other. One team may want a specific release near the end of a month, while for another group, there is a ‘drop dead’ need to have specific features in by the middle of the month. Reconciling them is easy if one of the teams is much stronger in terms of influence, since then the schedule will be driven by the more powerful team. However, when this is not the case, then the release timelines can get difficult.
There was one such team that was run by a colleague of mine. His team used to work on the traditional waterfall, and that was a disaster zone since they had to forever be ready to release for some team or the other. After much consultation, the team decided that a Scrum model would work better, especially since they could time the length of their Sprints, and have software available in a fairly good state at the end of every Sprint. So, they worked out a Sprint schedule whereby they worked out a Product Owner, and all requests needed to go through the Product Owner, and the time period of every Sprint was 4 weeks.
However, by the start of the second Sprint itself, it became clear that 4 weeks was just not making it. They had expectations from client teams that would just not work based on a release every 4 weeks (for example, there was a team that was very near release, and needed quick support for bug fixes – so they needed a turnaround time of a week for getting a new release that fixed bugs; the monthly cycle would just not work for them).
The technology team did an evaluation, and really did not want to move away from the 4 week sprint cycle (they felt that they were not mature enough in Scrum to try and handle a Sprint cycle of 1-2 weeks, and wanted to ensure that their team got a month to work and release features). Eventually, they came out with a solution that seemed complicated, but that seemed to work. They would still work on a 4 week Sprint cycle, but added some additional tasks to the Sprint backlog for coordinating a weekly release. This required some dedicated coordination from the ScrumMaster and some team members and went through some additional challenges, but after around a month, they were able to do this in a way that met the needs of the client teams. The team would ensure that when tasks were added for the Sprint backlog, there was an effort to time the expected output of the tasks, and then testing was added so that at the end of every week, a release was possible with a high level of quality. One could call this as saying that they had moved to a Sprint cycle of 1 week, but this was not true, specifically when it came to planning for the Sprint (that was done one a monthly basis).

A description of Scrum For Project Managers – some details

ashish — Sat, 04 Sep 2010 20:03:47 +0000

The product requirements of Scrum are typically chunked into a small set called a Story, or feature, with a short narrative description, somewhat like a use case or a test case. When you talk to people who are involved in Scrum, you will hear the word ‘Story’ many times. Let us go into more detail of what a Story is. There are three types of stories namely: User Story, Technical Story and Bug Report. More details on each of these. A User Story describes what the user does with the software and how the software responds. A Technical Story is a non-functional requirement that describes the functionality supporting the user facing features in User Stories whereas a bug report is a description of the failure of the product to behave as designed and expected. Another important document in Scrum (one of the most important documents) is called – the Product Backlog; which includes all requirements not yet scheduled for implementation.
Another important term in Scrum is Sprint; in the old world, Project Managers call it the Schedule, but this is not an exact mapping. Small teams of 6-9 people work in short Sprints of 2-4 (the optimum Sprint timing is dependent on many factors, including the work to be done, the comfort level, etc) weeks to implement stories in rank order. In each of the Sprints the team members collaborate and self-organize; they also track progress and update tasks when finished. Team members collaborate to complete stories quickly instead of working on separate stories in parallel. At the end of a Sprint, completed stories are shipped: incomplete Stories are not. The schedule is not extended to complete work.
The three roles defined in Scrum are: the ScrumMaster, the Product Owner and the Team. The people who fulfill these roles work together closely, on a daily basis to ensure the smooth flow of information ant the resolution of issues. ScrumMaster is responsible for enforcing the process, tracking progress and expediting problem resolution. He keeps the team focused and productive, protects them from interference and ensures the swift removal of roadblocks. It is not required that a person like a Project Manager should be the ScrumMaster, you need a person who can keep the team moving, can understand the Scrum process, and can work quickly to resolve issues that the team faces. The Product Owner is the keeper of the requirements. He provides the single source of information about the requirements and their planned order of implementation. The Team is a group of people responsible for developing the product.
The different phases of development in scrum can be divided into three phases. During the first phase the SprintBacklog is defined and ranked set of requirements planned for implementation in a Sprint. Next is the turn of sprint planning meeting where the team estimates each Story in rank order. Next is the turn of task breakdown; in which identification of the set of tasks whose execution results in implementation of the desired functionality. Phase two consists of developing and testing of the Stories. This phase also includes monitoring and controlling which maps to updating the Burndown Chart and holding Daily Scrum meetings. Daily Scrums are daily status meetings to resolve issues proactively. An important practice of daily Scrum Meetings is that it is timeboxed to 15 minutes, which essentially means that questions are answered quickly; issues are identified and addressed quickly. The final final phase consists of Demo, Release and Retrospective. Closing maps to demonstrate the completed work in review meetings is done. The updated product is released and the Retrospective meetings held to capture the lessons learnt. At this point the cycle begins again. The next Sprint kicks off with the Sprint Planning Meeting using the updated ProductBacklog.