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

This has been a series of articles that deal with how the Scrum team can improve their velocity (refer the previous post on the same topic). In this post, we will continue to talk on some of the points and efforts that can increase the velocity of the Scrum team. Here are some more points:
– Ensure that bug fixes are happening along with new feature work. In a Scrum model, the quality of the completed features needs to be great at the end of the Sprint cycle, and it needs to be emphasized that the team ensures that enough time is available for developers to do bug fixing while they are doing feature work (else, it will happen that the developers will be faced with relatively long periods of time when they will be doing feature work, and then, more problematic, long periods of time when they will be doing bug fixes, something which can reduce their efficiency).
– Get your team to think of ways to improve their efficiency and hence their velocity. You might be surprised by how suggestions float from your team members if they see that their suggestions are valued and can actually be acted upon. You need to ensure that they have it in their minds to improve their processes, and for this, you need to remind them at crucial points about the need to suggest improvements (including putting up posters on the walls that encourage them to post suggestions, awarding gifts to people whose suggestions are implemented, and so on)
– Make sure that your customer representative is on close call. It can be a challenge to have the Product Owner available almost all the time, but keep in mind that when your team members have some query and these are not answered, it could very well be blocking them, or cause them to make some assumptions on their own (which can turn out wrong in many cases and cause effort that is not useful). This also means that if the team is not clear on some of the points of the User Story during the time when the Product Owner is explaining the Story, or during estimation, the Story should not be pushed through without clarifying the doubts. If pushed through, there is a fair chance that the same doubt will come up later and can cause loss of time at that point.
– A proper feedback mechanism at an individual level for their estimations. By using Planning Poker and other similar methods, it is assumed that a more accurate estimation has been derived, but in many teams I have seen that people do sometimes get swayed by the estimates made by other people. In such a case, it makes sense to ensure that the actual effort put in is compared against the estimates put in by individuals, and feedback provided if there is a consistent issue seen in terms of under or over estimation of tasks on a regular basis. Getting people to get more accurate at estimation is one of the biggest parts of ensuring that the team delivers as per their capacity.

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>