Here are three most often asked questions / challenges organizations face (in estimation and related aspects) when they go through a major transformation to Agile. How would you address them / approach the challenges?
- We have implemented relative sizing approaches at a team level. Since it is largely driven by individual teams, how do I know (as part of being in the leadership team) that these teams are indeed improving? How do we differentiate teams that are actually doing better than others?
- One of my teams strongly feels estimation is a waste of time – time that can be better spent in actually producing software. Are they right in thinking that way? How do you deal with such teams?
- When estimating at an epic or feature level, typically only the senior designers or architects are involved. They are all comfortable in estimating epic or feature sizes in terms of gross person days of effort (Epic A will take 100 days, B will take 150 days and so on). What is your view on this approach?
Suggested Solutions:
1. We have implemented relative sizing approaches at a team level. Since it is largely driven by individual teams, how do I know (as part of being in the leadership team) that these teams are indeed improving? How do we differentiate teams that are actually doing better than others?
Since relative sizing works at a team level, teams use their own baselines for story sizes and hence arrive at a velocity they believe they can achieve. As a result, improvements need to be driven by individual teams themselves. The trust that the leadership team places on teams will in turn create ownership in them for their own improvements. Obviously, what the teams deliver and improvements over time will be corroborated by customer feedback on the deliveries made. The leadership needs to support them in their improvements efforts and not worry about metrics that the team needs to track themselves. I have shared my experience on this in one of my earlier blogs
The other question about comparison of productivity across teams – one needs to understand that there are so many variables that affect productivity of teams – including hard aspects like skill and experience level of team members, complexity of the software delivered in addition to soft aspects such as motivation levels, customer commitment/support, quality of leadership in team and so on. When so many such variables are involved, is it even fair to compare productivity of teams using a number you arrive at as an organizational baseline based on questionable standards? Such comparisons would also lead to changes in behavior that are not desirable –those that I have seen include a defensive approach by teams to estimating incorporating buffers, conflicts between POs and teams on estimates, conservative commitments, and inaccurate reporting of data by the team to name a few. So the answer is not rewards based on comparisons but rewards based on what teams accomplish by themselves and using customer feedback.
2. One of my teams strongly feels estimation is a waste of time – time that can be better spent in actually producing software. Are they right in thinking that way? How do you deal with such teams
This is clearly something where you need to look at the context. One of the reasons for doing any estimate is to be able to forecast and deliver on commitments. In other words, is the team predictable with respect to their commitments. If a team is able to do this consistently over time without doing formal estimates, they must have some mechanism that enables them to do this. They may not call something an estimate or a process for estimation but they must have some ways to plan and deliver on commitments that has some built-in estimation thinking. Some teams use number of stories by themselves as an estimate, especially when the stories have been broken down into approximately equal of similar sizes. For tasks, teams do task break down of a story bbut not detailed effort estimates – through their collaboration and tracking they are able to manage inter-task dependencies and completion. So the question here is the team’s intent and maturity level. If either of them is suspect, they will need coaching and counseling as needed.
3. When estimating at an epic or feature level, typically only the senior designers or architects are involved. They are all comfortable in estimating epic or feature sizes in terms of gross person days of effort (Epic A will take 100 days, B will take 150 days and so on). What is your view on this approach?
This may be OK especially for roadmap level planning where we are mostly doing very high level forecasts of delivery dates and budgets associated with them. It is also fair that at this level only senior folks are involved as such forecasts are purely for budgeting and not commitments. If they are viewed as commitments then a larger and more representative team may need to get involved. I have seen some organizations use story-points / epic points instead of gross effort in person-days but I would believe any of these is OK as long as the purpose is to identify a roadmap when major features will be delivered and to do budgeting and high level capacity planning based on that.
