A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

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

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.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>