Tipping the Scale

By A. Narasimhan

One reason why Scrum is more popular than other agile flavors may be that it can be applied to all sizes of organizations. Because it can be scaled easily, Scrum is a good fit for both large and small teams. Just because scaling is easy, though, doesn’t mean it isn’t complex. You should be very cautious when deciding to scale to a new level.

You might need to add a second level if:

• You have several interdependent Scrum teams that need to communicate often and feel the need for formal communication among ScrumMasters or among teams.
• You have several teams working together on a single product, with inter-dependencies across modules. The teams need to consider interdependencies and risks due to these dependencies while planning their sprints. They would need a formal structure to enable proper planning.

Implementing the second level is easier said then done. Organizations should understand the true needs of such a structure. Planning a second level of scrum requires, at least, the following actions:

1. Set the number of teams and ScrumMasters at the second level;
2. Implement Scrum at the second level (including planning, daily scrum and reviews) just as you did in the first level;
3. Formalize collaboration meetings and set them at definite intervals, as they are the forum for discussing dependencies and making decisions that will impact several teams at first level;
4. Allow for process overhead incurred by the additional meetings and collaboration.

It is a good practice to fix the frequency and duration of second-level collaboration meetings, partially because the broad agenda of such meetings needs more focus. This agenda includes some specific items:

• Discuss dependencies across modules;
• Facilitate resource sharing across modules/teams;
• Confront issues that have escalated from the first level to the second level;
• Identify risks at the second level; and
• Share lessons learned and best practices from the first level that can be used across teams.

Though it is not advisable to share resources across teams, sometimes large development teams, especially during the first few sprints, cannot avoid sharing resources. In a team of 100, there normally may be about 5-8 database experts, 10-15 designers, and so on. Until the teams learn to take cross-functional tasks and until the expert centers are removed, sharing of resources might be needed. In such situations, the second level of Scrum would be a good platform to make decisions on resource sharing.

One of Scrum’s strengths is its flexibility. Even so, you should consider your organizational needs before deciding to scale Scrum. The complexities a second level introduces must be worth their cost.

Keep Your Team Seeing RED

By Nimesh Soni

True project success can be summed up in one acronym: RED (requirements gathering, estimation, and delivery). Each of these key activities is crucial to a successful project launch.

Requirements Gathering

In Scrum, we write user stories to capture a project’s ever changing requirements. Because project needs fluctuate, Scrum doesn’t consider requirements gathering to be a one-time task. Instead, Scrum focuses on the incremental unfolding of requirements. The work is decomposed and captured at different levels in varying levels of detail during the project. At each level, the work is broken down into smaller, more manageable pieces of work.

Product backlog (PB): High-level capabilities and features are captured as user stories. The PB is the repository of all the work that needs to happen during the project.

Sprint backlog: The team identifies the user stories that will be worked on during the current iteration, or sprint. Each user story is decomposed further into tasks.

User stories should be validation-centric. The team needs to identify and write down the validation conditions for each user story. The story should not be closed until these validation conditions are met satisfactorily. As Ron Jeffries mentions, user stories have three critical components (the 3 C's of User Stories): cards (physical medium), conversation (discussion surrounding stories), and confirmation (tests and validation that verify story completion). 

Keeping the INVEST acronym in sight can also help agile teams write better stories. A user story should be:

Independent:
A good story should stand on its own.

Negotiable:
A good story is negotiable. It is not an explicit contract for features; rather, details are co-created by the customer and programmer during development. A good story captures the essence, not the details.

Valuable:
A user story should be valuable to the business.

Estimable:
The team should be able to gauge the size of a story.

Small:
A good rule of thumb is that a user story should not be more than eight to sixteen hours of effort. 

Testable:
The story should include validation criteria.

When writing individual, detailed tasks under each user story, teams should focus on writing SMARTtasks.

Specific
Measurable
Achievable
Relevant
Time-boxed

Estimation

Once the requirements are captured as user stories in the product backlog, the business will want to know how long it will take to develop the product and when it will be delivered. Estimation is done in two stages: at the individual user story level and at the sprint level (velocity).
The team assigns story points to each user story. These points are an indication of how long each story will take. One story point might be eight developer hours or two developer hours, depending on the team’s estimation scale. One way to calculate these point estimates is by using planning poker. User story-level estimates are usually done at sprint zero (release planning); they also might be done during sprint planning for each iteration.

Accurate estimates can be achieved through:

• A better understanding of user stories. A better understanding allows team to write clear user stories with "just enough" detail to enable the team to have a conversation with the business (customer) at a later date. Having the dedicated and active involvement of the business will help the team to understand and write better stories.
• Clear identification of validation for each user story. The validation should be written before estimation. Having validation clearly defined with the user story will make it very clear to the team what effort is involved for the story and when the story can be closed.
• Active involvement of the business. Having the business involved at all stages (sprint zero/release planning, planning for each sprint, and sprint review) will enable the team to have proper priorities for each sprint. The business will also be there to clarify any user stories that might confuse the team.
• Cross-functional teams. As Mike Cohn mentions, "planning poker brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else" (Agile Estimating and Planning by Mike Cohn). Having a cross-functional team enables the team to provide more accurate estimates.
• Planning poker: Using planning poker with a cross-functional team will ensure that you get accurate estimates.
• Clear definition of done: Clearly defining what must be completed before the team can say a user story is “done” helps the team provide accurate estimates.

The second level of estimation, sprint level estimation, is a “progressively elaborated” technique. As the team moves from one work sprint to another and closes various stories, it soon can determine its velocity: a measure of how many story points the team is able to close within a sprint. Based on the estimates and known velocity of the team, it is possible to forecast different dates within the release plan and predict how many sprints will be required to complete the project. Feature-level burnup charts can also help teams track their progress at the release level and provide more accurate answers as to when the product will be delivered.

Delivery

One promise of agile is "potentially shippable product increment" (Mike Cohn) at the end of each iteration/sprint. During each iteration, the Scrum Master (SM) should ensure that the work the team committed to do during that sprint is what the team actually delivers.

• The SM should ensure that the team understands the user stories and provides accurate estimates. 
• Once the team commits to a unit of work (and is in a sprint), the SM should make sure that the team is focused only on the user stories that are within the current sprint.
• During the sprint, the SM should also ensure that the team is focused on the sprint work (and only the sprint work). He/she should eliminate any impediments that might be blocking the team’s progress.
• The SM should maintain the task burndown chart and story burnup charts, along with the team’s velocity calculations.

Along with these tasks, I also used the spikes in the sprint burndown charts to gauge the quality of the estimates. We also added a dashboard report that was posted on the sprint wiki page and updated regularly. This one-page dashboard report lists the goals of the sprint, and the status of each in terms of red, yellow, and green, where green signifies on track/completed and red symbolizes off-track. This dashboard report also lists any known impediments/issues and status on each of them (open or closed).

By continually focusing your team on RED (requirements, estimation, delivery), you’ll be better able to keep your project in the green.  

The RED Grid

	Requirements	Estimation	Delivery
Tools & Techniques	User story cards	Planning Poker Story Points	Velocity  Feature burnup chart
Key Roles	Business (Business stories) Team (technical, enabling stories)	Team along with the business/product owner	Team
Key Concepts / Guidelines	Write in the format "As a <role> I want to <action> to deliver <business value>. INVEST 3 C's of user stories Validation centric	Write validation first (before estimating) Define DONE Create a cross- functional team with active, dedicated business involvement	Each work sprint should produce potentially shippable, working product Refactoring

The Three-Headed Product Owner

My company had a fairly good transition to Scrum. The team adapted well to the change and we all felt very lucky with how well things were going. Even so, when my colleague and I got back from our Certified ScrumMaster course, we were amazed by how easy it was to spot some little problems that had previously gone unnoticed. It was immediately obvious to us that, though we had a product owner, he was “missing” in many fundamental ways.

We weren’t the only ones who noticed this. A week after we returned from training, the team mentioned the same problem at our retrospective meeting. Clearly, our product owner, who was also the product manager, was not doing what the team needed and expected him to do. We decided that we needed a commitment from someone to really take on the product owner role. But who?

The product manager was not very interested in “driving” the team. This was evident from his recent acceptance of a number of features that clearly were not complete because of debug information popping up everywhere on the screen. We had a senior manager who was very supportive about Scrum but he was too busy to commit more than 25 percent of his time. We weren’t in a position to hire someone to do the job either. It soon became obvious that I had to do something myself. I volunteered to be product owner for the team.

I am a technical guy, not a salesman or marketing guru. I could commit to being there for the team, but wasn’t sure I had the point of view the team needed in a product owner. Luckily, we’ve been able to think outside a strict interpretation of Scrum and take three important steps that have helped me be the kind of Product Owner the team needs.

Step 1. Direct Meetings

Thanks to my recent ScrumMaster training and some reading I had done on my own, when I took over as product owner my understanding about Scrum had reached the level where I could look after the already prioritized and estimated product backlog and organize the review and planning meetings.

In the beginning, I felt a bit unprepared, but I dove right in anyway. Right after I took the position, I created a proposed list of product backlog items for the next sprint and presented them to the team the same day. I started calculating the completed story points and told the team that I would sit with them during the sprint and be ready to answer questions and execute acceptance tests when asked to do so.

The team never mentioned it, but I sensed that they might have been a bit worried about my ability to provide user feedback. Yet, at the very next retrospective meeting the team reported that the problem with the missing product owner had been pretty much solved.

Step 2. Form a Customer Team

We’re a product company that has always been driven by the sales team—they historically had specified the features that need to be developed based on the sales they wanted to complete. I come from a technical background. How could I provide feedback for the team that would come from a sales point of view? How could I be sure which features were the most valuable to our business? I couldn’t. Not by myself. Yet I was the product owner.

To give the project the correct perspective, we formed a customer team that includes a product manager who is good at spotting market trends and knows the competition, the senior manager I mentioned previously (who makes most of the decisions regarding features priority), a member of the pre-sales team who receives a lot of customer feedback, and me. We meet together periodically to answer any outstanding questions, to turn feature requests into user stories and add them to the backlog, and to assign and prioritise based on benefit, penalty, risk, and cost. I am the sole point of contact for the development team. When a question arises, I consult with at least some of the other customer team members to arrive at an answer the represents the customer team’s point of view.

Step 3. Create User Proxies

The customer team improved things for the development team. However, other departments began to feel as if they had no mechanism to provide us with their feedback. We were inundated with feature requests from our support and services departments and had quite a few from sales and marketing as well. We needed a way to deal with those and still make sure the team always worked on the highest priority items.

About that time I read about user proxies. They seemed to be the solution to our problem. Now, the other departments maintain prioritised lists of feature requests. Twice a month, they give us an updated list, indicating any changed priorities and added or dropped features. The customer team reviews the lists and balances these needs against the other items in the backlog before setting the final priorities.

Are Three Heads Better than One?

Having one product owner who is supported by a customer team and user proxies works for us. But let’s look at whether it satisfies the key components of an effective product owner.

• A basic knowledge of how software is developed and deployed
  Check. Coming from technical background and knowing quite well all the technologies involved, I more than met this criterion.
• An active stakeholder management
  We think we’re doing the best we can. Organizing the customer team meeting and collecting feedback from other departments might be the best you can do in a product company. Of course we would love to be able to receive feedback directly from the users, but right now it seems like we have some way to go before this could be achieved. 
• A thorough understanding of customer needs
  Yes, for the most part. Understanding the needs of over three hundred customers is always going to be a challenge. We get feedback from every single department that communicates with clients. Since each of these departments interacts with many different client levels, from decision makers to end users, we should be getting a good picture of client needs. We also have data available from customer satisfaction surveys and training feedback that we use in customer team discussions. Most, if not all, of the customer team members also sit in the review meeting and take part in deciding if a story is done.

After reading a number of books on Scrum and attending ScrumMaster training, I wanted to do Scrum as close to the books as possible. However, in our real world situation, it wasn’t feasible to find a single product owner who satisfied all of the necessary criteria. After looking at the situation we took a three-pronged approach: 1) A product owner who could take part in the planning and review meetings, update the product backlog, and help the team to get their answers 2) A diverse customer team and 3) User proxies to help the team make informed decisions when prioritizing the product backlog. Will it work for other teams? Who knows? Inspect and adapt!

Scrum and Group Dynamics

By Jörgen Fors

Given that Scrum has a very pragmatic view of getting things done and a strong focus on teamwork, how do the psychological aspects of group dynamics affect the likelihood that Scrum will succeed? Two interesting theories on the subject, FIRO and RAT, have implications for Scrum, yet I have not seen them referred to in any Scrum or agile material. Understanding these theories and their implications can affect whether a Scrum team succeeds or struggles.

FIRO

The theory of Fundamental Interpersonal Relationship Orientation, FIRO, was put forth by psychologist Will Schutz in 1958. He developed this theory during the Korea conflict, when he was assigned the task of explaining why teams with equal training and tasks achieved quite different results. Schutz found that team performance was directly related to the way team members interact and communicate.

FIRO divides the life of a team into three phases: Inclusion, Control, and Affection. Each of these phases measures how much interaction the individual team members desire in the areas of socializing, leadership, and responsibilities (and more intimate personal relations as well).

Inclusion describes an immature team, where individuals are focused on belonging or not belonging to the team. Individuals on an immature team are very polite as they attempt to orient among the other team members, achieve acceptance for themselves, and decide whether to accept others. The motivating need of the individuals is to feel important enough to be allowed to be a part of the team.

Control describes a team where individuals are focused on determining their relative position on the team. Individuals often have a confrontational or guardian behavior towards the rest of the team as they measure their own position in the group as opposed to the other team members. The motivating need of the individuals is to feel competent enough to be able to influence the team.
Affection describes the relations of a mature team, whose individuals focus on how close or far away from other team members they want to be. Team members in the Affection phase act openly and transparently towards each other and share both thoughts and feelings. The motivating need of the individuals is to feel loved and liked enough by the others.

Teams will become fully efficient in solving whatever task they have to do only when they have reached the affection phase. The task of the team leader (ScrumMaster), then, is to guide the team into Affection as quickly and efficiently as possible.

RAT

Elias Porter’s Relationship Awareness Theory (RAT) holds that all people want to have relationships with other people. From birth, human infants seek positive connections with their caregivers. Interaction and relationships with others give our world meaning. Therefore, our behaviors are expressions of our innate desire to be connected with others. RAT looks at how we behave to establish and maintain these relationships so that we have a positive sense of ourselves and our value as people.

1. Behaviors are tools used to get some result or confirm our sense of self-worth. Behaviors are also used to ward off things we do not want.
2. Motives come from our wish to feel a strong sense of self worth or self value.
3. Our individual Motivational Value System is consistent throughout our life and underpins all of our behaviors.
   Individual needs (and the resulting behavior) can change, depending on whether a person is stressed or not. So, a person’s behavior is predictable when calm and likewise predictable when under stress. However, calm behavior does not affect the stressed behavior. For example, a person can be friendly and helpful when calm, only to become controlling when under stress.

RAT divides individual behavior into three main types, all of which reside to some extent within an individual: Unselfish and caring (UC), Sure and controlling (SC), Analytic and independent (AI). In between these types are mixed behaviors.

All of the behaviors can be strengths of an individual and assets to the team, unless exaggerated. When the behaviors are exhibited to the extreme, they will be perceived by others as weaknesses of the individual. A common source of conflicts is when individuals of different behavioral types try to evaluate and judge each other. For instance UC and SC types of persons might experience the AI type as uncaring and uninterested.

FIRO in the Scrum environment

Now, let’s examine how these two theories affect the Scrum environment and see if we can use the information to find even more efficient ways of performing Scrum.

When we form a Scrum team and physically locate the individuals together, we create an undisturbed environment where the team is allowed to travel through the phases of FIRO. Scrum also sets a framework for how this journey is to take place by introducing a number of routines. During the inclusion phase, this framework allows new members to feel welcome and have some stability in an otherwise new world, where they are figuring out their roles.

The good news is that being located together and having routines lets Scrum teams make a fast transition to the Control phase. The bad news is that, once teams reach this phase, Scrum offers little help on how to get through this phase and become an effective team. On the contrary! Scrum explicitly states that the team shall be “self-organizing,” a directive which places a huge demand on the leadership skills of the ScrumMaster. One thing Scrum does provide, however, is some pressure regarding what is expected by the team (the sprint backlog) and during which timeframe it is supposed to happen (the length of the sprint). From a psychological point-of-view, the daily scrums and close cooperation enhance team spirit and enforce the bonds of the team. Forcing the team to focus on the task at hand also helps move the team into affection. At the same time, however, the pressure acts as a filter, where the weaker team members run the risk of being forced off of the team. Realize, too, that until an unfit member officially is lifted out, the team as a whole can not progress from Inclusion into the later phases.

While new Scrum teams will most likely perform better than teams using traditional development methods, no truly remarkable results can be expected by any team until they reach the Affection state. This is a good reason not to change the team between sprints, as every change in the team composition inevitably will throw the team back to the Inclusion phase. A strong team well into Affection will recuperate quite quickly, while newer teams might take considerable time to rebound, if in fact they ever do.

RAT in the Scrum Environment

RAT has different implications for the Scrum team. Just as different behavioral types apply different styles when acting as leaders, they also require different styles to be led.

A new group needs external stability and assurance. The team as a whole will have a need for a firm and self-assured leader—an authoritarian or, in RAT terms, someone with strong “Sure and Controlling” behaviors (SC). However, as the team passes into the Control phase, they no longer need this style of leadership. Since FIRO tells us that most of the group’s energy in this phase is spent finding internal team rankings, an SC-style of leadership will be seen as a direct challenge for rank, leading to confrontations. A better leadership style for teams in this phase is an Analytic and Independent (AI) leader, one who is skilled at “trickery.”

Once Affection achieved, the AI style will become obsolete. Any “trickery” that worked before to get the team to perform will be immediately seen through and ignored by this more mature team. Fortunately, the Unselfish Caring (UC) type of leadership is very well suited for leading a team that has reached this phase. This leadership style is also very much in line with the Scrum view of the ScrumMaster as “a remover of impediments,” i.e. both an authority and a servant to the team.

Based on this information, both FIRO and RAT theories suggest that selecting the right ScrumMaster is crucial to a team’s success. Not only must the ScrumMaster be well versed in the Scrum methodology, he or she must also be able to adopt different leadership styles, based on the current maturity of the team. Without a talented ScrumMaster to guide new teams through the early stages of their Scrum adoption, they may never move past the inclusion phase to one where they are truly productive. A good ScrumMaster serves as a catalyst for the team’s bonding process.

If your team is not performing as expected with Scrum, start looking at your own leadership style and ask yourself what can be done to help the team move into Affection. Keep teams intact or, if replacements are necessary, make them swiftly. Finally, be sure to appoint scrummasters that are able to use different leadership styles, depending on the situation at hand and the current needs of the team!

References

Schutz, W.C. (1958). FIRO: A Three Dimensional Theory of Interpersonal Behavior. New York: Holt, Rinehart, & Winston
Personal strengths publishing, 2007

Why switch a failing waterfall project over to agile?

By Anthony Heath

Many people assume that only new projects should switch to Agile. That’s not necessarily true. Switching a failing waterfall project can inject new life into a project, giving it a chance for success.  Moving to agile has both long-term and short-term benefits. 

Long-term benefits

Long-term benefits include increased project awareness for new team members, restored confidence in the original project concept, and the inclusion of clear and present business critical design requirements that were not evident at the project inception and thus fell out of scope.

While waterfall projects fail for many reasons, there is a direct correlation between failed projects and overall project timescale. Part of the reason for this is that long projects often see a fair level of staff turnover. New team members may not understand the original project or may have never been fully integrated when coming onboard. After a certain period of time, even the original team members have difficulty maintaining a clear view of project goals, no matter how well they were articulated at the onset of the project. Switching a failing project from a waterfall-based form of project management to agile methods gives organizations the opportunity to review project goals, analyze past performance, and refresh the project team’s understanding.

Short-term Benefits

There are clear short-term benefits in switching to agile.  As costs rise and no deliverables are produced, failing projects often fall under the critical eye of top-level management.  A switch to agile allows a project to start producing recognizable results in the short term.  This will help to raise the falling opinion and remind the organization of the initial perceived value of the project.

A switch to agile is especially beneficial when a project is struggling to pass the test and review stage. The agile method is especially suitable in this situation as it inherently promotes quick turnaround, fast response, and instant solutions.

For a project with an out-of-control budget, switching to agile will allow for tighter financial control across the much smaller agile iterations. When planning a far-reaching waterfall project, budget is often calculated incorrectly, as it is almost impossible to foresee every possible future problem. Agile, on the other hand, allows for shorter budgeting periods, clearer indication of future budget requirements and tighter controls on overspending.

Conclusion

Waterfall projects often bog down when plans don’t match reality. Switching these failing projects over to agile can yield both immediate benefits and long-term improvements. The implementation of the agile methodology, including its iterative approach to software development, allows a failing project team to quickly revisit and redevelop problem project areas as needed.  This single benefit alone is often enough to save the project, as results no matter how small are deemed preferable to no results at all.

Success Factors for Scrum Implementation

By A. Narasimhan

My company recently implemented Scrum on a large team developing an enterprise product. Three factors were responsible for our success: customer ownership, management commitment, and the cooperation of the development team.

Customer ownership

Our development was an internal initiative. We had a US-based business unit that was the sponsor and the direct customer for the product. We also had an Indian development arm. The end users were also involved with development in some cases. The enterprise product was targeted at hospitals worldwide.

The directive to use Scrum actually came from the US-based business unit (the sponsor and direct customer for the development unit.) This turned out to be a tremendous advantage. After all, one of the major components of Scrum is customer involvement; if the customer is not fully involved it is difficult for them to fully own the product features and prioritize and review the backlog every increment. Even when the customer is committed, some of them are not fully aware of how release management happens in Scrum. This was definitely not the case for us. Our customers not only understood Scrum, they were the first to get educated about Scrum and spread its use to the development team. Having customers that are well-informed Scrum proponents was instrumental in our success.

Management commitment

The second key to our success was the complete commitment of the Indian management to the Scrum process. Not only did they have a basic understanding of Scrum, the also clearly saw the need for proper infrastructure, training, and tools. Their commitment made it easy for the development teams to properly implement Scrum. 

Development cooperation

It often is relatively easy for a small team (ten to fifteen members) to successfully implement new methodologies. But our development team was large (several hundred members). This required a high level of coordination and cooperation among team members. Our large team had to work together as a single team, where previously we had independent design, development, test, and quality teams. The mix of skills in each Scrum team introduced new challenges. The scaled Scrum structure brought with it additional process needs. Team members were involved in more meetings and discussions, which required them to collaborate much more. All of these changes were implemented quite smoothly because of the development team’s enthusiasm and willingness to learn.

Naturally, there were many other factors that helped us in making Scrum implementation successful, but customer involvement, management commitment, and the cooperation of the development team contributed the most.

Predictability in Action

By Aaron Sanders

Earlier this year, I found myself in a familiar situation. I’d once again been wooed by a small start-up company that is growing in size and looking to hire senior expertise because of a major deal inked with a large organization.

The staff of the small startup were both exhilarated and stressed from working so hard to make the effort attractive to major players in the market. A year of doing whatever it took to get product out the door had taken its toll—two of the original developers had already called it quits. I wasn’t sure what I had gotten myself into, but I was excited about the possibilities. One thing I was sure of—their waterfall process was not going to get the job done. Let me take you back there and walk you through the switch we made and the results we achieved.

Rewind

It’s January 2007. I’ve just begun work at my new job. I immediately start pairing with anyone who checks out code. I notice that there is an infrastructure with some automation of builds, data replication and testing, so they definitely are not way off in the weeds. The product is web based and built with fairly robust open source systems.

The recently hired project manager is working with the creative director to come up with a fairly heavy process to accommodate the anticipated growth and to ensure success in the new partnership. They have printed out a graphic representation. The business development director is on a road show with the owner, promoting their wares. When the duo arrives back in the office, they find a note I’ve stuck to the graphic representation of the proposed process. It reads, “traditional waterfall.”

Meanwhile, I sit down with the project manager and ask if he enjoys writing use cases. Throwing down his pen on the desk and pushing back, he spins to me and states, “Heck, no! I can’t get anybody to read them, let alone approve them.” So I ask if he would be interested in hearing about a process where we wouldn’t have to have it all written down by him before we began. He’s interested.

After some education of the terminology of the practices, we invite the owner, business development director, and engineering manager to a discussion over coffee, where we go over what it would mean to introduce the agile methods of Scrum and XP to the organization. We discuss roles, how to generate and estimate the product backlog, length of iteration, and what day to start.

I explain the need to separate authority from responsibility by not placing the role of ScrumMaster with the engineering manager. We decide that this would be a good role for me. We determine that the project manager should be the product owner, as the business development director is gone too often. Since the project manager is also the system architect and has the most domain knowledge besides the owner, he is mentioned as a possibility for customer as well. Because this would stretch him thin, we convince our actual customer (partner organization TradeMe) to engage with us in that role. Already one incredible thing has happened, we’re now thinking more in terms of the product than of projects.

Since the team is already recording tasks and defects in an open source issue-tracking program, it is a simple matter to extend the fields to accommodate story points and hours remaining. Because people tend to be out of the office more often around a weekend, we decide to start sprints on Wednesday and have them run fortnightly.

The product owner and creative director convert all the tasks into user stories, breaking some things down, aggregating tasks together, and rewording them to be customer facing. Once the stories are written, the team gathers to play a game of planning poker. We find a small story that we all agree is worth one point, and then look at a couple of recently finished stories to help calibrate size. We then start to build historical data to help with initial velocity calculations.

Many of the interesting things involved with an estimation meeting start to happen: discussions over items too vague or big to be estimated, the true value of a particular story, breaking dependencies, and how to implement certain pieces. The meeting moves slowly. I try to break off discussion when it no longer seemed beneficial. After a few hours, we’ve only estimated a dozen items and have over a hundred items remaining. Still, the team declares the meeting a total success because they have enough for the first sprint.

Fast-Forward

It’s now mid-March. We have the majority of the backlog estimated and prioritized. Three sprints under are our belt, not counting sprint zero, which we used for preparation and learning (much like playing a hand of cards face-up). All this clarity into the effort involved leads to the director admitting that the contract negotiated with the customer (our partner, TradeMe) is fixed in both scope and deadline. It took six months to come up with the contract, and at this point we have only four more months until we’re supposed to launch the working product at the end of June. Our own estimates put the completion date for the product somewhere between mid-August and the end of October. We’ve got a bit of a problem.

The director and product owner work very hard to keep the product backlog prioritized. They sort things into themed stories well and do a good job of balancing out the work load. However, they want to be much further along and are constantly trying to push more work on the team. I decide to relent. Instead of planning April’s last sprint, we take on everything the contract specifies should be done by us at this point. Our best and last sprint finished fifteen story points; the work remaining is ninety points, seven times more work than has ever been completed in a sprint. Even with the director’s help coding, by the end of the sprint most of it is still incomplete. Neither the estimation date nor the velocity have changed too much.

In May, the suggestion is made that perhaps the stories are estimated incorrectly. How could the team be certain that something was worth five points while something else seemingly completely unrelated would be worth eight? We group user stories that have the same estimated point value to see if they are truly the same size, including finished stories. This comparison does show that some stories should be a different size or be re-categorized. We recalculate the velocity. Our estimated completion date still falls, at best, in September and, at worst, in November. Neither is close to the July deadline promised in the contract.

Fortunately we are now working in constant contact with our partner/customer because they are functioning as the customer for the sprints. They can check out our code and build in their environment. We have them on the phone for sprint reviews. The constant interaction clarifies that this project cannot go according to the contract. What they have seen accomplished to date makes them want different things, and some of these changes require direct input from them. This is a dependency we cannot control.

Eventually we all agree that the contract “nice-to-have” date is indeed more flexible than we thought, with a “drop dead” date beyond the fixed term of the contract. As I look at our sprint estimation, we are now knocking down about twenty points per iteration, with about 170 points yet to go. We are cruising to an October launch.

Play

After a couple more iterations, and well past the original deadline, it is made clear that the software needs to ship soon. Collaboration is high, with some of our developers working at our partner’s site. An incentive deal is reached: if people are willing to work weekends from now to launch, everyone will get a bonus week’s vacation immediately following launch. Perhaps this helps. The software launches on 7 September 2007, well within our original prediction of mid-August and the end of October.

Our agile estimates were proven correct. They helped to interject reality into an unrealistic contract. This agile estimation thing really works.

The Company: Vianet

The universal marketing system for tourism that utilizes the latest mapping technology and real-time booking capabilities to give travelers complete destination information.

The Partner: TradeMe

68 percent of New Zealand's internet traffic is to online auction site TradeMe, CEO Sam Morgan and Development Manager Rowan Simpson told me when I visited their Wellington office. TradeMe is New Zealand's version of eBay, even down to the color scheme. But it's more than just an auction site now. Over the past seven years it has expanded into major verticals such as jobs and motoring. Also it's probably New Zealand's biggest social networking platform (even though it's not strictly speaking an Social Networking System).

Even considering all that, when TradeMe sold for a cool $700 million New Zealand dollars earlier this year to Australian media company Fairfax, the price tag astounded many people in New Zealand and Australia. At the time, that amounted to nearly $500 million US dollars. To put that into perspective, it was a deal worth approximately 15 times more than the much more hyped sale of Flickr to Yahoo the year before.