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 ?

In the previous post (Scrum team – Difference between Capacity and Velocity), I had talked about some of the reasons as to why the capacity of a scrum team is different from that of its velocity. In this post, I will try to explain how we can bridge this difference. Most teams do not see a case where the Velocity of the team is greater than its capacity; the problem that they typically try to solve is the case where the Velocity of the Scrum team is less than the Capacity of the Scrum team (and this becomes a significant problem when the team delivers far less than the amount of features promised at the beginning of the Sprint). So, in this post, we will try and work out some ways that the team can learn from their Sprint efforts and improve their Velocity.
– The first major factor is to ensure that the team does a retrospective at the end of every Sprint, and does it with full effort and with a desire to learn what went right and what went wrong. Which also means that the atmosphere in the team should be such that people should be able to talk about what went right and wrong in an open setting.
– Should be able to re-visit various criteria and other process through the various cycles based on feedback. Part of the emphasis on Scrum is being able to incorporate changes in requirements and other such factors; but changing processes based on feedback is much more difficult. As an example, suppose the team works out that the criteria used to judge whether a task is done needs to change, then there should be an ability to incorporate such changes in processes.
– In some cases, when a team is getting into Scrum for the first time, external stakeholders may be worried about the ability of a team to deliver, and would be measuring the output of the first Sprint. Further, the team would also be watching the Velocity at the end of the first Sprint, so it becomes even more important that the First Sprint be planned much more thoroughly to ensure that the Velocity of the First Sprint is much closer to the capacity, and the desired set of features are delivered.
– During the course of the planning, the team should sufficiently feel ownership of the processes. Teams that are successful leverage the experience of their experienced personnel, such as refining the criteria of Done, design processes, requirements, task estimating, source control; and can lead to a much higher level of efficiency. It is important that such an exercise be done to discuss processes, get improvements from the team members, and be on the lookout to even modify these if required. Such efficiencies leads to an increase in Velocity.
– Calculating metrics for time capturing and other such metrics helps in the calculating of Velocity, but this data by itself does not give the true reasoning for the impact on Velocity. It is important that when any event happens that can impact the development (and effect the Velocity), the team members capture such events and these are discussed during the Sprint retrospective. One should not jump to conclusions based on data driven Velocity, but do a more thorough discussion on the reasons that led to the feature not being done.

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>