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
Friday, February 10, 2012
Sunday, October 30, 2011
Scrum & Fixed-Bid!
One of the primary concerns of the software practitioners about the Scrum framework(or Agile methods in general) is its adaptive nature as opposed to the conventional prescriptive approaches. The common question that is usually thrown around is “How can you estimate and present a bid if you are Agile? How does it work if the customer expects a fixed bid?” This article tries to answer that question in the few paragraphs that follow.
Without even to get into the very fundamentals of Scrum, a quick thought about the framework makes the thinker focus on three important aspects:
Time-box: The projects based on the Scrum framework are time-boxed which means that the period of activity is fixed, usually one to four weeks for a sprint and one to three months for a release. What this means is that the development team tells the customer team “We will give you something at the end of this period”.
Scope negotiation, not time: As the time is fixed and quality can never be compromised up on, the only point of negotiation here is scope. So, instead of buying more time to address the entire scope scheduled, the agile teams reduce the scope to fit to the schedule in the event of their inability to complete everything that they said they would.
Prioritization: All the items that are being developed using the Scrum items are ranked as per their value and worked upon in the same order. This means that the items with the highest importance are attempted first and in case the team is bound to miss some items, they are usually from the bottom of the list, i.e., the items of lower value (Unless, of course the team misses a huge part of its target).
Now, coming to the bidding problem, the ideal situation is that the team bids for the project on a Time & Material basis, in order to accommodate the changes in an efficient manner. However, many customers prefer to know the costs ahead so that they can plan their budget better. So, the challenge is to find a way to fixed-bid a Scrum project.
It is not as difficult as it sounds.
Yes, the difference is significant, let us examine why.
The time is fixed and so is the cost. So the customer would know exactly what they are spending. This helps them plan their budget better.
Negotiation is on the basis of scope. So, even in case of any slippage, the customer and the development teams do meet their deadlines, albeit with limited scope. The release happens as planned on the committed date and this helps the team enormously since there is “certainty” as far as the release is concerned.
Cutting the scope down!!. History tells us that a lot more than half of the features required upfront are not used. This is mainly because the product owners tend to club “Nice to have” features with “Must have” features. Since the Agile projects get executed on a priority basis, the teams always complete the features with highest value first so that in case they miss some feature, that usually falls within the range of a feature that is seldom used and the product owner could even decide not to implement that feature in the near future.
The comparison is clear - in the traditional style, the development team gives everything to the customer with additional cost and on the Agile way, the customer gets the minimum viable product on time. What is better?
The bidding approach is not difficult either - Once the customer lets the scope out, the development team could do a quick vision planning that results in “Rough order of magnitude” estimates. This ball park estimate gives the teams the initial direction and the decision making advisory.
Then the team would plan the releases with story points. This should not take much time since it is not really detailed and the estimates are in terms of story points. Once the story point range is known, the team would match its velocity with the story point scope and then presents its bid, based on the number of releases required to deliver the features requested by the customer. The team may also advise the customer about the features that may not add value to the customer, there by leading to savings.
Then the interesting part - if the scope changes during the course of the development activity, which usually would, the changes are handled within the time-box. The scope changes, but not the estimates. If the requested (new) feature is of high priority, then the feature(s) matching the effort needed to develop the new feature would go out to the next release. So, the time is preserved and the value of the release is enhanced – a Win-Win!
To summarize the concept, in a fixed bid environment, the team commits to a “fixed quantity” of features that would add maximum value to the customer. The set of features may change, depending on the evolving needs of the customer. This is in contrast with the traditional methods that make the team commit to a fixed set of features.
How does Agility address the other challenges related to the fixed-bid projects that are sourced out?
Team challenges:
Quick and free communication among the team members - Eliminate communication gaps and waiting
Transparency and total visibility – Build trust
Lightweight processes that use “Just enough” formalities – Minimize waste
Information Radiation – Detect problems early and minimize risks
Completely aligned teams – Resolve dependencies efficiently
Scrum of Scrums – Manage the whole Program
Process Challenges:
Fixed time (Time-box) and Committed Size/Throughput
Variable scope to facilitate flexibility
Change Management through Iterative Release & Sprint Planning
Iterative planning to gradually eliminate uncertainty and get better at estimation
How does it map to key project management practices?
Scope: Epics, User Stories & Prioritization, Backlogs, Story Points
Time: Time Boxing, Sequencing based on Priorities, Velocity, Task Hours
Quality: Defect Prioritization & Management, Test-Driven Dev.
Communications: Stand-ups, Reviews, Retrospectives, Informal communications
Risk Management: Impediment Tracking & Removal
Integration: Continuous Integration and Builds
Cost, HR and Procurement can remain the same or customized as per the needs
The comparison is clear - in the traditional style, the development team gives everything to the customer with additional cost and on the Agile way, the customer gets the minimum viable product on time. What is better?
The bidding approach is not difficult either - Once the customer lets the scope out, the development team could do a quick vision planning that results in “Rough order of magnitude” estimates. This ball park estimate gives the teams the initial direction and the decision making advisory.
Then the team would plan the releases with story points. This should not take much time since it is not really detailed and the estimates are in terms of story points. Once the story point range is known, the team would match its velocity with the story point scope and then presents its bid, based on the number of releases required to deliver the features requested by the customer. The team may also advise the customer about the features that may not add value to the customer, there by leading to savings.
Then the interesting part - if the scope changes during the course of the development activity, which usually would, the changes are handled within the time-box. The scope changes, but not the estimates. If the requested (new) feature is of high priority, then the feature(s) matching the effort needed to develop the new feature would go out to the next release. So, the time is preserved and the value of the release is enhanced – a Win-Win!
To summarize the concept, in a fixed bid environment, the team commits to a “fixed quantity” of features that would add maximum value to the customer. The set of features may change, depending on the evolving needs of the customer. This is in contrast with the traditional methods that make the team commit to a fixed set of features.
How does Agility address the other challenges related to the fixed-bid projects that are sourced out?
Team challenges:
Quick and free communication among the team members - Eliminate communication gaps and waiting
Transparency and total visibility – Build trust
Lightweight processes that use “Just enough” formalities – Minimize waste
Information Radiation – Detect problems early and minimize risks
Completely aligned teams – Resolve dependencies efficiently
Scrum of Scrums – Manage the whole Program
Process Challenges:
Fixed time (Time-box) and Committed Size/Throughput
Variable scope to facilitate flexibility
Change Management through Iterative Release & Sprint Planning
Iterative planning to gradually eliminate uncertainty and get better at estimation
How does it map to key project management practices?
Scope: Epics, User Stories & Prioritization, Backlogs, Story Points
Time: Time Boxing, Sequencing based on Priorities, Velocity, Task Hours
Quality: Defect Prioritization & Management, Test-Driven Dev.
Communications: Stand-ups, Reviews, Retrospectives, Informal communications
Risk Management: Impediment Tracking & Removal
Integration: Continuous Integration and Builds
Cost, HR and Procurement can remain the same or customized as per the needs
Friday, September 16, 2011
Removing team dysfunctions by using Scrum
One of the great threats to the functioning of a team is a set of 5 dysfunctions that could plague the team. These dysfunctions build upon one another and could negatively affect the team in such a way that the team would eventually crumble. This factor shows how Scrum framework can effectively help the teams remove the dysfunctions.
Click here to view my article in Tools Journal. The article discusses how the Scrum frameworks helps the teams in removing their dysfunctions.
Subscribe to:
Posts (Atom)