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..) ?

In this series of posts, we are talking about teams can improve their Velocity and make it closer to the Capacity of the team. So, we have been looking at ways to improve the velocity of the Scrum teams, such that you can get the Velocity closer to the theoretical capacity of the team. In the previous post (Improving Scrum Velocity), I had stated some points that could help the team in their quest to improve the Scrum velocity. Let us take some more points in this post:
– Understand that it takes some time for the team to determine a velocity level that seems somewhat stable. When a team starts to get into the Scrum cycle, it takes time (upto 3-4 Sprint cycles), for the team to get into a proper way of being able to estimate tasks, and execute those tasks (and this is without any attempts to optimize the team velocity). The team can start measuring velocity from the beginning of the first Sprint, but it will take some time for the Velocity to settle down to something that seems constant (in the first couple of Sprints, the team starts to increase their own efficiency and their estimation methods). You may have to live with this kind of time lag for getting an estimated Velocity for your team.
– If you are working in a corporation with multiple projects, then it makes sense to prepare a library of the documentation related with different Scrum projects (that would include projects with different team sizes, different technologies, different durations, and so on). What this does is to give a team access to other teams that may have conditions similar to their teams, and this helps give them a benchmark to compare their Velocity with (so that if their benchmark is way lower than that of a team with similar conditions, then there is quite obviously scope for improvement).
– Need to try and reduce churn in your team. If you have an environment where there is a lot of churn within your development team (with people leaving, or more experienced people being posted to other projects with a higher priority), then the Velocity of the team can get affected fairly strongly (with the effect being almost always a negative effect).
– The experience of the team has an effect on the team Velocity (although getting people with requisite experience may not be totally within control). Consider that you have a team that is petty well experienced in how Scrum projects work, and have a lot of experience in doing so effectively. As a result, you will get a team that settles down very well, has already done the kind of tweaking that increases the efficiency, and requires much less coaching. However, this factor is not totally within control, since everybody would want to have experienced people, but the resources that a team gets is dependent on various factors.

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>