Negotiating the Date

It was the end of fall and our customer said they needed the work finished by the start of spring. Everyone wanted some buffer in case something delayed deployment and we agreed to finish development by the middle of winter. This date was written in to the contract drawn up by lawyers and signed by both sides. The rate that we were now building the product at had our team estimating we would have something out after the date in the contract.

Inspecting Progress

Our customer attended reviews, inspected progress by checking out and building the latest code at any time, and saw our responsiveness from requests in planning. It was because of this interaction that when we told them, they understood that we had more work to do than could be delivered by the contract date. Everyone believed the data they were seeing.

Working Closer with Our Customer

The customer then upped our trust in them. They told us that the intention was to go live in the early summer. Our velocity and Product Backlog size showed that we would finish most of the work by the end of spring. The customer worked closer with us, providing frequent feedback on the direction.

We worked together deciding on what to build next. People from both companies traveled between the two sites. Our Product Owner seemed calmer. Everyone understood clearly what to do and we launched within the window predicted. The customer eventually acquired vianet.

As part of our Scrum practice at vianet, we spent time as a team tending to the Product Backlog. We played planning poker and kept all our stories sized. We knew the entire size of the Product Backlog. Every Sprint we looked ahead and refined some User Stories.

Our velocity was stable and we could predict what User Stories would fit in a Sprint. The total size of the Product Backlog and the number of Sprints left projected that we would not hit the date promised to the customer.

Verifying the Estimates

The Product Owner started to question our estimates. He neither questioned the technique itself nor the merits of relatively sizing items, just the numbers we produced from this estimation technique.

We decided to spend a day with the Product Owner looking over the backlog. We looked at some of the work we’d finished to help calibrate sizes, and triangulated it with the items not yet started. Some of our User Story estimates changed. We sliced some of our User Stories thinner and even removed a couple. The Product Owner was convinced that our estimates were sound.

When we finished and totaled up the points, it was nearly the same as the beginning number. We learned that keeping the backlog sized is priceless and that reassigning points is useless. The total size of the Product Backlog had not moved a significant amount from all of our work, although we now were intimately familiar with it.

Time for a Talk

This didn’t help the fact that we all recognized that we needed to have a tough discussion with the customer.  We couldn’t deliver on the date we promised with the features they wanted.Икони на светци

Vianet established a cadence around Scrum and soon our customer, stakeholders, executives and others would ask how the current Sprint was going. The people asking questions numbered more than we had on the team. The questioning increased as a Sprint neared its end.

I asked if people could hold off with the questions until the end of the Sprint. It had become too much of a distraction for the team.

Designing Good Retrospectives

A friend suggested that I read “Agile Retrospectives” by Esther Derby and Diana Larsen. The book was recommended to me to help weave activities together to get the most out of a retrospective. In reading it I noticed that the effect could be amplified by tying retrospectives together for another level of build-up, from one retrospective to the next.

It’s suggested by most Agile Coaches to only put in a couple of hours to prep for the Sprint review. I would invest up to three hours preparing for a good Sprint retrospective and another hour and a half to facilitate. I spent some more time writing up summary notes to help us remember decisions, and to help me design the next Sprint’s retrospective.

Communicating Results

At the end of the Sprint we would have our review and take feedback from our customer and others. When asked how we thought the Sprint went we could usually point out that we had once again met our commitment and if not, a quick explanation why not.

Further comments from the team, we insisted, would have to wait until we could have our retrospective. We decided in our retrospective what information we wanted to share out, which was mostly conclusions and next steps.

Better Interactions

Our team constantly improved from how we practiced retrospectives and we made a habit of relating afterwards how we felt about the Sprint. While we included feedback from Sprint review into our planning, we would also explain our plan for improvement that came out of the retrospective.

The questions dissipated and we could work without as much distraction. This allowed us to meet our commitment and celebrate it in the Sprint review.???????? ?? ?????