Sprint Velocity calculation in Jira
Hi, dear and respectful community!
With all respect to you I have the question how to calculate the best way the velocity in jira.
My team just moved from Kanban to Scrum and we just started our first sprint today. We would like to track sprint velocity and currently it is based of story points of stories + we agreed on 20% for QA debt. QA debt we manage in tasks (separate epic). But in jira task type we don’t have story points estimation. Would it be fine if we have sprint velocity in story points and capacity for QA debt tasks in hours, for example? And it will look like:
Sprint velocity: 50 SP QA debt: 21 hours
but this way we have two types of estimation and difficult to make mapping of those. So, it looks a bit messy
Or should we change in task type the estimation type from hours to SP in task type? and no headache with different types of estimation
If you are estimating, using two different estimation units very often causes issues. I would recommend that the team choose one method of estimation and only use that. With the choice between hours and story points, my recommendation would be hours, and specifically ideal hours, for two reasons:
- Hours are useful for looking outside the team's planned product development work. People plan vacations in hours (or days). Scrum Events and other meetings take hours. You can set aside timeboxes for hours for other work, like you do with timeboxing technical debt paydown. You can calculate your ratio of ideal time to calendar time to improve your planning.
- If you decide to shift to a No Estimates approach, you'll likely be using throughput, cycle time, and lead time as some key metrics. Cycle time and lead time would be measured in time - hours and days. You'd also be able to measure things like touch time (when you're actively working on an item) or wait time (when an item is waiting for the next processing step). You would move from planning in one form of hours to another form of hours.
Although I tend to personally favor No Estimates and the flow metrics, not all teams are ready for that. Estimating in ideal hours can be a good stepping stone for teams currently using relative estimation in points, t-shirt sizing, or other methods.
Sprint velocity: 50 SP QA debt: 21 hours
but this way we have two types of estimation and difficult to make mapping of those. So, it looks a bit messy
It is messy. Velocity is the rate at which work is Done. That's it. Any work that does not meet the Definition of Done cannot contribute to velocity.
If nothing has been quality assured for example, velocity is zero.
Hi,
People struggle with one estimation technique and you are trying to use two (story point and hours) :). You should be sticking to just one say story points. In Jira you have a velocity chart which will show commitment vs actually achieved and you can take the average of the last 3 sprints to determine your average velocity. There is something called as sprint insights in your Jira and it will give a view of your average velocity and a range for what you should commit to during the sprint and I have found that to be pretty useful.
Also agree with the point mentioned by Ian rather than compromising the QA why not adjust scope such that what is done is completely done without any compromise on quality.
Is QA less important than Developing? If not, why treat it differently?
The teams I have worked with that were most successful with estimates treated everything equally. When work was estimated, it was done in its entirety. One estimate was determined by the entire team for all work associated. That included development, testing, documentation, etc. Anything known was estimated. Anything unknown was dealt with as it was learned.
Personally I'm a fan of No Estimates like @Thomas but I leave it up to the team to decide what they want.