Question: “How do you measure a team’s true velocity if they have underestimated a story, or a story turns out to be harder than they had anticipated?

Say for example, the team estimates a story at 8 points, and they finish it, but in retrospect they say the effort involved was actually 13 points. But you only count the 8 points. 

Would you change the estimate after the completion of the story so that you have a better idea of how much the team can get through in an iteration?”

http://www.linkedin.com/groupItem?view=&gid=52030&type=member&item=103649676&commentID=74234886&report%2Esuccess=8ULbKyXO6NDvmoK7o030UNOYGZKrvdhBhypZ_w8EpQrrQI-BBjkmxwkEOwBjLE28YyDIxcyEO7_TA_giuRN#commentID_74234886

My Thoughts: Hmmm. True velocity. I’m not sure there is such a thing. Average velocity – maybe. 

Why do you want to know the precise true velocity anyway? If it is to measure the team’s productivity, then we have one set of problems. If it is to be able to more accurately predict the product backlog items (PBIs) that will make it into the next release, then there is another set of issues. 

Story points are about inherent size and complexity of a PBI. Velocity is the rate, in real time, of how long it takes a team to accomplish PBIs. Does the team want to revise the story points because the inherent size or complexity was underestimated, or because the PBI took them longer then they thought it would? 

Let me assume that you want to know the “true velocity” so that you can more accurately forecast the PBIs that will be finished by some target date in the future. In that case, you are most interested in the velocity number that reflects the rate at which future PBIs will be accomplished. Since the yet-to-be-worked-on PBIs were likely estimated with the same knowledge and assumptions that the team used to estimate the story in question at 8 story points, then leaving the story at 8 points may be the best for your purposes. 

Story points are only an estimate. Some estimates will be high and some will be low. By breaking the PBIs into small enough units, there should be enough of them so that the highs and lows average out. Velocity for a sprint has little meaning. Average velocity is much more useful.

Vertical slicing does not prohibit up front design. It simply forces you to validate integration of the architectural pieces for each and every product backlog item. Many agile teams use a “sprint 0″ to sketch out the architecture and decide on the design mechanisms they will use to flesh out the architecture. Then, each and every sprint, some amount of the sprint planning meeting is spent considering design issues for that sprint. Teams have design meetings as needed. Agile techniques do favor making design decisions at the last responsible moment, but usually the responsible thing to do involves at least some up-front design work.

Just because traditional methods created too much up-front design doesn’t mean that to be agile implies no up-front design. A good agile team will always be struggling with the issue of too much vs. too little up front design. Vertical slicing adds much needed stability to the inherently risky business of building something the team has never built before.

All too often I see teams that have adopted the form of Scrum, but have missed the essence. It is quite possible to have an ordered backlog, 2 week sprints, sprint planning meetings, daily scrums, retrospectives, etc. and still not be agile. One common way to have the form of Scrum without the essence is to treat Scrum as a series of mini waterfalls, with code thrown over the cubical wall on day eight and all testing relegated to designated team members at the end of the sprint. Worse yet, the teams could decide to perform testing one sprint out of phase with development. Another very common pitfall is to have different Scrum team members reporting to different line managers. Some of these issues are bigger impediments than others. As I have worked with different organization using Scrum, in my mind they seem to fall into one of three categories based on the maturity of their level of adoption of Scrum.

At level one, which is by far the easiest level to attain; the team adopts the roles, rules and artifacts of Scrum: daily standups, sprints, product owner, ordered backlog, etc. The sad thing is that teams often mistakenly think that this level of adoption of Scrum is all there is, and that once they have learned to play by the rules of Scrum, they are truly agile. This is a bit like thinking that once you have mastered the rules of chess you are a chess master. A team can fully adopt the form of Scrum without achieving true collaboration, transparency, or a Keizen mindset. A characteristic of being stuck at this level is the attitude that once the team has mastered the form of Scrum, a ScrumMaster is no longer needed. After all, anyone can update the burndown chart and facilitate a few meetings, that is not a full time job, right?

The second level of Scrum maturity comes with the team and team members adopting agile and lean values and principles. Now the focus in on things like

• Sustainable pace
• True cross-functional collaboration
• Technical excellence
• Fixing problems as they occur, to get quality right the first time
• Finding how to achieve the productivity of enabling specifications within an empirical process
• The PO, ScrumMaster and Development team gelling into a single unified Scrum team,
• Continuous improvement
• Value to the client by building truly exciting products

At this level, team members willingly share their knowledge and cross-train each other. The team has good domain knowledge and helps the PO define and create a truly exciting product. The team is acutely aware of impediments, both internal to the team and external to it and is continuously working on resolving them. At this level, everyone realizes that both the PO and the ScrumMaster are full time roles. The daily scrum meetings are seen as valuable co-ordination meetings. If the team has gotten past fear and command and control, the PO and ScrumMaster might even participate in and report their activities during the daily Scrum.

The third level of Scrum maturity requires the organization to enable teams to become fully self-organizing, self-managing, hyper-productive, Scrum teams. At his level the organization makes the kinds of changes detailed in “The Leaders Guide to Radical Management.” The focus now changes from:

• Short term profits à delighting customers
• Preoccupation with internal efficiencies à continuous value stream for end users
• Command and control à enabling and self organizing
• Contracts à Collaboration
• Rules à common sense
• Silos à complete teams
• Fantasy à Reality
• Plodding à excitement

This means things like:

• No individual team member metrics
• Phase based activity metrics are replaced by product metrics
• No individual performance reviews
• Teams are truly self-managing. Team members report to the team.
• The focus changes from people and detail process management to product and portfolio management
• Command and control structures are morphed into enablers. For example if the project management office (PMO) stays around, it becomes the Agile Enablement Center.
• No treating new product development as a manufacturing activity
• Estimates are not treated as commitments.

Unfortunately, this third level of maturity is kind of like world peace. There are too many impediments for it to occur on a large scale in existing organizations. Just like we can have regional peace, organizational Scrum can and has happened in divisions of large companies and even entire smaller companies, especially start-ups. But in the same way that world peace is impeded by

• hatreds, fears, and mistrusts that are centuries old
• existing power structures that would be threatened
• huge changes to economic structures
• philosophical and religious differences
• etc.

The corporate adoption of Scrum is impeded by

• fear and mistrust
• existing power structures that would be threatened
• huge changes to economic structures
• philosophical differences about how to manage people and the role of organizations
• etc.

I don’t claim any rigor or theoretical basis for the three levels of maturity introduced above. I simply use them as a practical mechanism to help Scrum adoption agents prepare for the reality that some transformations will be easy, some harder, yet with more benefit, and that the most important will face very stiff opposition. I also use these three levels to get teams to realize that there is more to Scrum than rules, roles, and artifacts.

We like to slice the product backlog small and vertically so that we can deliver business functionally quickly. I’d like to add another business reason for vertical slicing. Two of the big risks faced by a development organization are 1) integration risk and 2) technical rework risk. When an organization builds a product based on horizontal slicing, that organization faces a huge end-of-project business risk that the pieces might not integrate easily, or at all. Then the business has nothing until technical rework is done and the all the pieces integrate. So by slicing horizontally an organization incurs both integration risk and rework risk. The hope was to avoid rework by using specialized experts to get each layer/piece right by doing a lot of up-front design. However, teams have finally realized that no amount of up-front design will guarantee no re-work when building something no one has never built before. So to reduce the risk of integration not going well we build vertical slices that force end to end integration for each product backlog item (PBI). There is still the risk that as I add more and more slices, that some rework may have to be done to keep the code and architecture clean. But at each step along the way I have an integrated functioning product. Thus the business risk of end game integration going poorly and ending up with nothing – until everything is fixed, is eliminated. Business hates risk, and by continuously integrating end to end, I not only provide functionality early, I eliminate the risk of end game integration failure.

 There are many ways to slice requirements. Seehttp://www.ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgileSuccess_Gottesdiener-Gorman_August2010.pdf but I use the use case framework to drive most of my requirements slicing. Use case scenarios can easily be found by varying preconditions of the base scenario. I have found that the alternate use case scenarios provide appropriately sized items for the groomed product backlog that have identifiable value to the product owner. The base scenario is often too big, so I do use the techniques in the PDF above to slice the base scenario.

Doing away with roles and titles on a Scrum team does not mean doing away with recognized expertise. It means we do away with silos and individual ownership that creates bottlenecks and mini waterfalls in a team. It also means that whoever has the best expertise on a given task takes the lead for that issue even if that person happens to be a “junior level” new hire. Doing away with titled roles, coupled with team metrics and incentives rather than individual metrics and incentives, also encourages cross-training and knowledge sharing which is core to increasing velocity and creating exciting products.

Salary classifications tied to job titles do typically hinder true collaboration on a team. However, I have not yet had the opportunity to work in an organization that adopts Scrum from top to bottom all at once. HR is often one of the last places to get Scrum and until they do, salary classifications tied to job titles persist. As long as I can get my Scrum team to ignore those titles within the team, Scrum can get a good foundation in the company. Removing job titles from the organizational structure can go on the impediment backlog – which like the product backlog is hopefully primarily ordered by long term ROI.