Measuring Team & Individual velocity

Rajasekhar Maddela September 6, 2018

Hello Community,

In my project, I'm dealing with a few challenges. Below are the most notable one's -

1. Tracking Team's true velocity for a sprint

2. Tracking an individual team member's velocity

To describe the first challenge in a little more detailed, we have a lot of stories in our sprint which get spilled over the current to the following sprint, because either Dev is still in Progress or QC activity is still pending. As a result, how can I determine the true velocity that we delivered for a give sprint.

The second challenge is more of a residual challenge as a result of the first one. It's equally difficult to determine the velocity of an individual. I don't intend to micromanage my team but this data will help me understand more about how productive an individual is. Appreciate any helpful inputs.

Regards,

Raj

1 answer

0 votes
Daniel Deng
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 6, 2018

We faced the same issue as your #1 when we started our Agile process. One of best practice of our team is to narrow the granularity of Story to the scope that can be completed within a Sprint. If something is too big to be a Story then use Epic instead. 

I did not see a good way from within Jira to track the individual's velocity either. However, from Agile point of view, it is not recommended to do it, all we care about is team's velocity, which is used to plan future Sprints. 

Rajasekhar Maddela September 6, 2018

Thanks Daniel, agreed.  However, what if the user stories have dependencies (say API) provided by other teams? I guess such kind of factors cannot be brought under our purview.

Daniel Deng
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 6, 2018

Yes, dependency is another headache. We usually identify dependencies in Sprint planning and try to decouple dependencies as much as possible for the coming sprint. However, if you have to plan a story with dependencies into your sprint and finally that dependency blocked the story by the end of the sprint, you may split that story into 2 part

1. The work you have done for this story in this sprint. This one stays in the current sprint and will contribute to the velocity.

2. Remaining work of the story, which depends on external factors. This one should be moved to the next sprint or the backlog

Rajasekhar Maddela September 6, 2018

ok makes sense. Thanks.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events