Product Owner: “That’s what we want, get the costs up front. We’re going to market our site as the most customer friendly.”
Tester: “Is there any way the user can screw up? What will they do on this page?”
Product Owner: “When we add the other shipping options, they can opt to change their shipping option. But for now, it’s really straightforward. We already have validation to make sure their postal code matches the city they enter for the shipping address.”
Tester: “What if they realize they messed up their shipping address? Maybe they accidentally gave the billing address. How can they get back to change the shipping address?”
Programmer: “We’ll put buttons to edit billing and shipping addresses, so it will be very easy for the user to correct errors. We’ll show both addresses on this page where the shipping cost displays. We can extend this later when we add the multiple shipping addresses option.”
Tester: “That would make the UI easy to use. I know when I shop online, it bugs me to not be able to see the shipping cost until the order confirmation. If the shipping is ridiculously expensive and I don’t want to continue, I’ve already wasted time. We want to make sure users can’t get stuck in the checkout process, get frustrated, and just give up. So, the next page they’ll see is the order confirmation page. Is there any chance the shipping cost could be different when the user gets to that page?”
Programmer: “No, the API that gives us the estimated cost should always match the actual cost, as long as the same items are still in the shopping cart.”
Product Owner: “If they change quantities or delete any items, we need to make sure the shipping cost is immediately changed to reflect that.”
As you can see by the conversation, a lot of clarification came to light. Everyone on the team now has a common understanding of the story. It’s important to talk about all aspects of the story. Writing user acceptance tests as a group is a good way to make sure the development team understands the customer requirements. Let’s continue monitoring this conversation.
Tester: “Let’s just write up some quick tests to make sure we get it right.”
Customer: “OK, how’s this example?
Tester: “Great start, but we won’t know where to ship it to at that point. How about a more generic test like:
Customer: “That works for me.”
Considering All of the Facets
Paul Rogers recounts a situation during an iteration planning meeting, where a performance issue came up for a story that appeared to be straightforward and quick.
During our iteration meeting, one of the stories we were discussing was for adding some new images to part of a web application. This discussion ensued.
Product Owner: “I’d like to also get in the story for additional images.”
Developer 1: “OK, who has ideas on how long it will take?”
Developer 2: “It’s fairly quick, maybe half a day.”
Developer 3: “But what about the database changes?”
Developer 2: “I included those in the estimate.”
Developer 1: “OK, let’s go with half a day.”
Me: “Hang on. We looked at some performance issues last iteration. If we add all those images, we will be taking a performance hit.
Developer 1: “OK, we should think about that some more. Maybe there are other ways of implementing it.
Developer 2: “Why don’t we do a quick spike, add the mock images, and run another performance test?”
It was really good that this discussion before even starting on a story gave us some ideas of what problems we may encounter.
Anyone who’s uncertain about either the impact of a story on the rest of the system or the difficulty of developing the functionality can, and should, raise an issue during iteration planning. It’s better to address uncertainty early on and then do more research or a spike to get more information.
Asking questions based on different viewpoints will help to clarify the story and allow the team to do a better job.
Writing Task Cards
When your team has a good understanding of a story, you can start writing and estimating task cards. Because agile development drives coding with tests, we write both testing and development task cards at the same time.