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, I have been talking about how to improve the Velocity of the team (refer to the previous article); in this post, I will continue on the same subject and present more issues that impact the ability of the team to increase their velocity. In this post, I will talk about some more issues that could impact the Velocity of the team and how they can work.
We recently saw a case where the performance of the team was being reduced somewhat because of the dependence on certain team members, and because the priorities of tasks was just not correct. As an example, the case was because there was a dependency that the QE team members had on the Dev team members delivering a particular feature. We had setup a sequence of tasks inside the User Story where the first set of tasks were to be done by a specific Dev team member, and then the QE of these tasks were to be done by another QE team member. The Dev team member would need to take 3 days for the task, and then the task would be available to the QE team member (and in the meantime, for the first 3 days, the QE team member would be working on documentation).
However, what happened in the task was that the Dev team member was on track for getting the task done in the 3 days, and then disaster struck. The dev team member had to take emergency leave on the 3rd day due to some personal problems, and was not expected back for atleast 3-4 days. As a result, we found that on the 3rd day, the QE team member was sitting idle, and we had not really had any other alternate task lined up for the QE team member. Now, people can need to go on leave, but one needs to plan for such eventualities, otherwise, as in this case, you would find that the team members are primarily idle.
What did we do ? Well, we were able to find some other tasks from below in the Product Backlog that was able to be independently done by the QE team member, and hence it was not a total loss; but this a lucky chance, else we were looking at losing productive time of around 3 days even for a team member who was at work. As a result of this case, we changed our process by ensuring that there were always some Dev only or QE stand alone tasks that were useful for the product, which can be used in such cases. So, when a similar case came up later in the cycle, we were able to handle this situation fairly seamlessly.

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>