If one looks at the total then everything looks fine when the velocity gets reported. The stakeholders are not much worried when the overall report is presented.
However, even though one hates to sub optimize the teams, the fact the Team B is slowing down cannot be ignored. Moreover, Team B missing 10 points has much more impact on the program Team A missing the same number of points. The usual practice is to ignore the difference and continue working with the teams.
Normalization:
This approach tends to normalize the story points across the teams belonging to the same program, thus giving the same context to any story point count across the teams. The basic idea is to have the same meaning for story points across the program.
The approach:
The approach is simple. We take the team with highest velocity as the baseline and extrapolate the points of the other teams with respect to its points.
In other words Normalized Point Count for a team = Old Point Count * Ratio of the velocity of the team with highest velocity to the velocity of the current tem.
For example, in the current context, the rough ratio of the story points across the three teams is 4:2:1,, which implies that 1 point on team C is equivalent to 2 points on B and 4 points on A. This, when we normalize the story points, we multiply B’s points by 2 and C’s by 4 to match A’s point count.
This can be managed in 2 ways: In the first, one-time normalization wherein the normalization formula is applied entire story set, (Completed as well as backlog) thus altering the effort context for the affected teams. In the second approach, the estimation happens as usual without altering the 1 point stories, but at the end of every planning meeting, the points are multiplied by respective constants to make the numbers uniform.
The revised table looks like
As one can observe, now “1 point” means the same across any team belonging to the program.
Distinct Advantages of this approach:
Points are defined consistently across the program
Reporting gets easier as the velocity is team context independent
Tracking becomes simpler
Risks:
Because we are presenting the same context, there would always be a tendency among the management to compare the teams
This might lead to competition at the expense of collaboration
Monday, October 1, 2012
Normalizing Story Points in a Scaled Agile Environment
Introduction:
Scaling Agile practices is a special challenge in itself. Practices do tend to get complicated when multiple teams work in tandem on various projects and programs. This paper address one issue that often has a high-impact on tracking scaled Agile projects. The focus of this paper is the way the velocity gets tracked across multiple teams working in the same program.
Velocity:
Velocity, commonly defined as the number of story points completed in an interval of time (Release or Sprint), plays a major role in tracking and predictability. The historical measures of the velocity are used in making predictions about future velocity. Velocity is also used to represent a team’s productivity.
While velocity is an extremely useful metric, it gets little challenging while dealing with the scaled Agile processes. When one program has multiple teams with different velocity targets, assessing the progress gets somewhat tricky.
For instance, consider 3 teams X1, X2 and X3 – X1 has a velocity of 40, X2 20 and X3 10. The expected velocity is 40+20+10= 70. Suppose the whole team reports a velocity of 65 on a specific sprint. Can we report 90+% progress? We cannot – for not all the points are safe. What if Team B has missed 10 points?
Consider the following table. It represents the velocity of three teams A, B and C belonging to the same program across various Sprints. Team A records the velocity that hovers round 40 points a sprint, Team B, 20 a sprint and Team C records 10. This is fine as the context of points is different for the above teams.
If one looks at the total then everything looks fine when the velocity gets reported. The stakeholders are not much worried when the overall report is presented.
However, even though one hates to sub optimize the teams, the fact the Team B is slowing down cannot be ignored. Moreover, Team B missing 10 points has much more impact on the program Team A missing the same number of points. The usual practice is to ignore the difference and continue working with the teams.
Normalization:
This approach tends to normalize the story points across the teams belonging to the same program, thus giving the same context to any story point count across the teams. The basic idea is to have the same meaning for story points across the program.
The approach:
The approach is simple. We take the team with highest velocity as the baseline and extrapolate the points of the other teams with respect to its points.
In other words Normalized Point Count for a team = Old Point Count * Ratio of the velocity of the team with highest velocity to the velocity of the current tem.
For example, in the current context, the rough ratio of the story points across the three teams is 4:2:1,, which implies that 1 point on team C is equivalent to 2 points on B and 4 points on A. This, when we normalize the story points, we multiply B’s points by 2 and C’s by 4 to match A’s point count.
This can be managed in 2 ways: In the first, one-time normalization wherein the normalization formula is applied entire story set, (Completed as well as backlog) thus altering the effort context for the affected teams. In the second approach, the estimation happens as usual without altering the 1 point stories, but at the end of every planning meeting, the points are multiplied by respective constants to make the numbers uniform.
The revised table looks like
As one can observe, now “1 point” means the same across any team belonging to the program.
Distinct Advantages of this approach:
Points are defined consistently across the program
Reporting gets easier as the velocity is team context independent
Tracking becomes simpler
Risks:
Because we are presenting the same context, there would always be a tendency among the management to compare the teams
This might lead to competition at the expense of collaboration
If one looks at the total then everything looks fine when the velocity gets reported. The stakeholders are not much worried when the overall report is presented.
However, even though one hates to sub optimize the teams, the fact the Team B is slowing down cannot be ignored. Moreover, Team B missing 10 points has much more impact on the program Team A missing the same number of points. The usual practice is to ignore the difference and continue working with the teams.
Normalization:
This approach tends to normalize the story points across the teams belonging to the same program, thus giving the same context to any story point count across the teams. The basic idea is to have the same meaning for story points across the program.
The approach:
The approach is simple. We take the team with highest velocity as the baseline and extrapolate the points of the other teams with respect to its points.
In other words Normalized Point Count for a team = Old Point Count * Ratio of the velocity of the team with highest velocity to the velocity of the current tem.
For example, in the current context, the rough ratio of the story points across the three teams is 4:2:1,, which implies that 1 point on team C is equivalent to 2 points on B and 4 points on A. This, when we normalize the story points, we multiply B’s points by 2 and C’s by 4 to match A’s point count.
This can be managed in 2 ways: In the first, one-time normalization wherein the normalization formula is applied entire story set, (Completed as well as backlog) thus altering the effort context for the affected teams. In the second approach, the estimation happens as usual without altering the 1 point stories, but at the end of every planning meeting, the points are multiplied by respective constants to make the numbers uniform.
The revised table looks like
As one can observe, now “1 point” means the same across any team belonging to the program.
Distinct Advantages of this approach:
Points are defined consistently across the program
Reporting gets easier as the velocity is team context independent
Tracking becomes simpler
Risks:
Because we are presenting the same context, there would always be a tendency among the management to compare the teams
This might lead to competition at the expense of collaboration
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment