How to break off your client's meeting

Some time ago I was at a client to facilitate an estimation meeting of a brand new Scrum team. At some point I broke it off and we didn't estimate at all. Instead we tried something completely different. When I told a friend about that he said "[This was] testing the readiness of a project to proceed" and told me to remember what tipped me off, what were the signs, how I investigated further before I broke it off, what happened next, what I might do different next time and how it turned out. So this is a story about testing. It will be thorough and long but hopefully enjoyable. The client and his meeting play an important yet secondary role.

Prologue - What tipped me off

This story has a little prologue. I was called to the client at very short notice. Usually I know that I will be at a client at least one or two weeks before I am actually there. This time it was different. The project started sooner than everybody thought and a colleague searched somebody to jump in. As my own two projects I was supposed to work on didn't start until a week later I was free to take over the first meetings to prepare the project.

Calling my colleague two work days prior to the workshop, I learned that everyone hastily prepared for the project start. Within a couple of days the Product Owner had to provide an initial backlog with only few information from his client. I was supposed to facilitate an estimation meeting to estimate the initial backlog. On top of facilitation, the team needed some guidance on how to estimate large amounts of user-stories.

So I asked my colleague if he had seen the backlog which was supposed to be estimated. He told me that he hadn't but everything would be prepared before I was to be there and that our client would have a meeting to establish the initial backlog with their client a day or two before the estimation meeting should take place. When I asked if they already had worked on a proper product vision to lead their decisions about priorities, he denied that. But he was positive everything would be fine and in place as needed. I trusted him. Then. But as I didn't get the answers I liked, I had a little knot in my belly.

What were the signs

When I called the client to make the appointments, we agreed that an initial preparation meeting before we wanted to estimate would be appropriate. They wanted to discuss the agenda and show me what we wanted to start with. When I went there I found the Product Owner and one of the developers who already had worked in an agile environment in his former job. Both were excited to a degree of being in a rush. Yet they explained very patiently what the whole project was about. They asked some questions of how I planned the next day and finally led me to their product backlog.

What I found was two pinboards with about 80 cards. Most of them had one or two words on them and everything seemed organized around bigger topics. So far no complaints. Then I took a closer look to find out which abstraction degree the backlog items would have. I found entries like "What is the key difference between our product and the competitor's?", "organization" and "easiness". On first sight I couldn't see any items that would make sense to me as a former programmer. Most of the items seemed more like principles or goals, not features. But on that day I didn't get a chance to ask further questions. Unfortunately everyone was in a rush and I was led back to a conference room. Rather suddenly my appointment ended and I was to come back for the estimation meeting.

By now I was sure that could be an issue and that I won't get them to work on a vision. They were so time-pressed that they tried to avoid anything time-consuming. But I was sure my experiences as consultant and trainer would guide them through these issues and provide enough help to succeed on a fine start to their project. Now I had to find out if the team that was familiar with the domain could handle the backlog items or if they were as lost as I was.

How I investigated further before I called it off

The next day began and the team came together for the first time. Now they were introduced to the new project and to new team members. After an hour or so the team had the opportunity to ask questions and one of the first things which someone asked was about the vision without me needing to add it. The answer was that their client was still working on the vision but that we would need to go ahead without until they were done.

Then my part began and I explained about how most teams come up with estimates in scrum and presented two different approaches: one for large amounts of items (magic estimation) and one for further investigation with unclear and controversal items (planning poker).

Finally the stories were presented and I watched what happened to the faces of the team members. Deep frowns. Discussions. Questions. Suddenly the Product Owner was pounded with questions. In the meantime some team members shrugged and blindly grabbed an item to pin it to the prepared pin boards. Confused remarks filled the room. I patiently answered questions but couldn't help them on their domain.

Eventually I called them off the boards and looked which items had changed their places twice and ended up in the parking lot section of the boards. By now I was sure the team was as lost as me with the backlog items. So I asked the Product Owner to provide some further information about the first of the parking lot items but to keep it short and focused on what should be the outcome.

I saw the Product Owner struggling and after she ended a heavy discussion started on what was in scope of the backlog item and what wasn't. Interrupting them I asked kindly to try planning poker before discussing the topic. As I assumed, the estimations offered a great variety of story points between 5 and 40. Further discussions and another estimation round didn't change anything even with the Product Owner struggling for explanations and the team stating what they understood.

What happened next

Obviously the whole team including the Product Owner was stuck. One side was asking for directions, the other side giving principals. My feeling hadn't been wrong, even with me guiding the Product Owner to clearer requirements the team was lost. Before we wasted more time I stood up and asked everyone to take a break. Just the Product Owner and the developer whom I had met in the preparation meeting were staying behind. Walking them to a balcony with fresh air I asked them to call the meeting off. Obviously the team needed a different style of requirements to be able to work. The first sprint was about to start and it was more important to find the first features to implement instead of insisting to estimate backlog items the team could not work on.

The other two agreed and I suggested to think about the end of the first sprint and what should be finished by then to get the best possible, say most useful, feedback on the product. We made first steps with this and finished a pretty decent planning the same day together with the team after they came back from the break. We ignored the existing backlog items completely and worked strictly on items which would make it possible to have a technically shippable first small product at the end of sprint one.

Using everyone's thoughts and ideas we came out with four new items which the Product Owner saw the most value in and the team had some ideas how to work on them. A big plus was that the first story would be a very slim crosscut through all levels of their system so that they would be able to probably have a running system on day one.

What I might do different next time

I didn't listen to my feelings when I called my colleague and again at the first meeting with the client when I saw the backlog. Given the chance with another client about to run into similar problems I would ask to see the backlog earlier to have some time to work on the issues even in the preparation meeting. That would have saved us a lot of time and some headaches. Learning how to estimate was not as important as having actionable backlog items for sprint one. Without a sprint backlog nothing will be achieved in an already time-pressed project.

It is exactly the same what I plan to do in testing: If I already have a knot in my belly and see another wave of pain coming, I should investigate further and ask questions to find the root cause and validate or falsify my assumptions.

How it turned out

In the after I asked my clients about feedback. The team had already left and had thanked me with happy faces which had been troubled by the time they had discussed the estimations. According to the first impression the client told me it had been exactly the right thing to do to break off the meeting. Even a day later when there was a meeting with their client they were still sure it was more valuable to have a sprint backlog for sprint one than to have estimated backlog items nobody could have worked on.

They even told their client what trouble they had and the client could inform them that he now had a proper product vision which he could present to the team the same day. After the presentation we knew that the work from the day before was safe: The few information which the team had had been enough to create a sprint backlog which nicely fitted into the vision. It turned out fine.

It felt rather familiar to see these things happen but I couldn't describe why I felt like that as I never broke off a meeting like that before. Not until talking to my friend I realized that I was actually testing. I tried to provide valuable information and didn't stick to the plan when I learned that things were different than expected but tried to validate my assumptions.

I take it as a successful day.