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.

Scrum: Making the team aware of their Velocity before they start committing for the next Sprint …

A few of the last series of posts talked about the Scrum team running into a situation whereby the actual time required for a feature was much more than the estimate. This was one of the problems that can pose a significant problem to the Scrum team and their productivity. A twist to the same kind of story is when the team is actually estimating in such a way that they are trying to do more features than are possible in the given time frame. So, what happens is that the team sees the list of features that are there in the Backlog, and actually does their estimating in such a way that they are promising more features than they can do in the given Sprint timeframe. But, how do they see such a thing like that ? A Scrum Master would have the ability to see that the team is actually doing less features than they planned out at the start of the Sprint. During training, it has been drilled into the team and the scrum master that one of the ideas of Scrum is not to pressurize the team into giving estimates that are less than the required time (in a given project using Waterfall, a standard practice would be for the team to get pressurized into estimating aggressively, and then working overtime to meet the number of features that were promised).
However, this does not mean that for a team following Scrum, such issues are not taken into account. Part of the issue of any team is to ensure that they are trying to be as accurate as possible, which means that for a team, the difference between the number of features that come through in the feature planning and estimation meetings and the actual number of features that get done in the Sprint should be as low as possible. But for this to happen, the team needs to have awareness of their work that is happening in terms of the amount of work that gets done in a Sprint and ensuring that based on this awareness, there is a correction made in their estimation abilities so that the aim of increased accuracy becomes more likely.
One of the best measures for this is called Velocity.
Velocity is a measure of how much work the team is able to get done in a Sprint cycle, and can be measured over the course of a few Sprint cycles so that the average of this measure over the sprint cycles helps to get a fairly great accurate figure of how much the team can get done in a Sprint cycle. The Scrum Master should be able to use this figure to work with the team and help them understand the amount of work that they typically get done in a cycle, which would help them determine the accuracy of their estimates. This can also sometimes help the team understand that they are progressing slower than what they thought they would; this translates into the team either being able to improve their productivity or coming to a better understanding of their abilities, which helps the team overall.

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>