Posted on

Parent Site

The team was given a story to estimate in backlog refinement. “Add an error message to the checkout page when details are missing for an order referred from our parent site.” We were given the design and text for this error message. The Product Owner presented it to the team for an estimate.

So why do I have a problem with that?

I’ll explain. One of our challenges is that we have business owners and product managers in another country who like to “save time” by

“doing the stories for us.”

Writing stories for the team doesn’t really save any time. Even worse, it’s in conflict with Agile values and principles. Stories written for a team are just a functional spec written in the form of a story.

But back to my story.

We were presented with this already written story on a shared screen with the Product Manager (in a Product Owner role) driving the computer from another country. (Yeah, I know that’s wrong but we can’t change that). However, the team is sitting with me. So this is what I do. “OK, let’s start at the beginning.” I turn the laptop around and video Skype the Product Manager. “Who are we doing this for?” I ask the team. In a few minutes we come up with the customer, Jenny, a persona we have used before. What does Jenny want? Well she wants to know if something is missing. Why? So she can fix it and continue with her purchase. Good.

Some background. We work for a subsidiary of a parent company with a site that has significantly more traffic than we do. Let’s pretend we sell clothes. On the parent site a customer will select a product, let’s say it’s a t-shirt. They can also pick a colour, a size, a currency for purchase and quantity of items and send those attributes to our site to purchase in our cart. The error message is for those times the customer ends up in our shopping cart missing one or more of those attributes.

I ask the team to give me stories. “What kind of information might be missing?”

We end up with a list of things Jenny might want to fix as well as “unrecoverable error, we have nothing”. We also assume we need a story to re-direct as far down the funnel as we can get so Jenny doesn’t waste her time.

We turn these into stories and prioritise them.

Jenny is on the shopping cart page, which of these missing attributes can be fixed on the shopping cart page? Currency and quantity. That’s a story. So our first story is about missing attributes that can be fixed on the shopping cart and the error messages for that.

OK, so what happens if Jenny lands on the shopping cart page and we don’t know the colour or size? We aren’t sure because that doesn’t happen on our site but we assume the shopping cart is empty because we need to know these attributes in order to put a product in the cart. So she gets an empty shopping cart with an error message. Jenny can’t fix that problem, can she? What can we do with this story so it gives Jenny the outcome she wants.

We know the product code. Story number two: we can take her to the product page with an error message so she knows what she needs to fix. On the product page she can pick size and colour.

What if we don’t know that product is actually unavailable? We can still go to the product page because we already have a version of that page when products are unavailable.

Maybe we don’t know the product code. Well we could drop Jenny back on the empty shopping cart with an error message. Is that really what we want to do? Our user story says Jenny wants to fix the missing attributes, can she do that? No. So that’s another story.

At this point in our story planning meeting we have a white board filled with post-its under the User Story “As Jenny, I want…” We also have a team that is engaged and thinking.

At this point, the Product Manager says “hold on, I will be right back.” OK. She comes back in a few minutes with a surprise guest, the business owner. I introduce myself and the team. Let’s go back to the top of the board. We go back through what we’ve written, talk it over and ask the Business Owner if she is happy with what we have so far. She is.

Now we move on to the next story: “unrecoverable error, we have nothing”. Where do we take Jenny now? The team had come up with “the Home Page”. The business owner says “we already discussed this, we don’t want people to land on the home page.”

We already discussed this.

I really hate that phrase. My snippy response would be “that’s funny, I have a really good memory. We have only been doing this for about ten minutes and I don’t remember discussing it.” But instead I explain we know we can’t take them to the product page because we don’t know what the product is. If we take them to the shopping cart, it’s empty so that’s just a dead end. So the team thinks in this story we should take them to the home page with an alert Is there a better option? Nope. Home page it is.

I know what has happened. The Product Manager, the Business Owner and perhaps a VP or two have already talked about this. They went straight into solution mode because that’s the fun part. They think the thinking is already done. They have already decided. Invariably when a management group decides on a solution, they don’t know the detail. They don’t have to. They only have to agree on the outcome they want. Where you get into trouble is when the team is handed a specific solution and asked to estimate that. We can do that. But then we don’t know what to do with all the bits they have left out. So we can ask them to document in great detail what they have decided so we can estimate that. We can do that but it’s called waterfall. Let’s not go there.

Back to our agile story mapping and MVP session.

Now everybody on the team has a clear understanding of the stories. We agreed on the stories that are in our MVP and we can estimate those. Actually it didn’t take very long at all.

What do we gain? Engagement, better stories, better estimations, more understanding of what we are doing and why.

What didn’t go well? The Product Owner says it is not up to the Scrum Master to decide what is in scope. Agreed. But it is up to the Scrum Master to protect the team and to make sure agile values and principles are upheld. The Product Owner can choose not to go ahead with any of the stories we have identified. But the team needs to do the story mapping.