Hi Valentina, a product manager here. 👋🏼 I think the problem you're describing it so acute, I've seen it many times. Adding detailed acceptance criteria with examples to the user stories definitely helps ease this.
I'd even go some steps further. I think what truly helps to achieve shared understanding in the product team is involving developers already in the discovery phase. It doesn't mean they have to take part in every user interview, etc. But I've seen it significantly helps in achieving a team-wide understanding of what problem we want to solve and why. Then ideating solutions together (devs, designers, product) also result in better solutions.
By the time we write those acceptance criteria, the whole team has a better idea of what we want to build, for who and why.
1. Understanding the problem, e.g. through user interviews. The is crucial, because if we skip this step, if we don't understand the problem we're solving, if we try to solve the wrong problem, then our solution is useless, we're then wasting our time. Yes, we should start with this, rather than jumping to the solution. I've had good experiences that, where possible, developers be part of some of those user interviews, to understand for whom they're building the software.
2. Specifying the solution, together, by formulating the system requirements. Everyone (PM/PO, Developers, QA Engineers, UX/UI Designers) should co-create the solution, because multiple minds are better than one. For one problem, there is a multitude of solution, and through this collaboration we try to choose the optimal solution, one that satisfies the business problems and minimizes development effort. Follow the Card -> Conversation -> Confirmation. Ultimately, the Acceptance Criteria are the confirmation, they are a precise formulation of the requirements through examples.
3. The team can then convert the Acceptance Criteria into Acceptance Tests which is the first part of ATDD cycle, so that ultimately what they build satisfies the Acceptance Criteria.
4. After we release the product update to users, we get feedback, we discover if we understood the problem or didn't causing us to repeat the process above based on feedback, and that's the continous cycle.
By writing Acceptance Criteria in a testable way, and aligning it with the whole team - the PO, Developers, and QA Engineers, so that everyone is on the same page regarding what we mean. This needs to be done before we start implementing a User Story.
Yes, the Acceptance Tests give you the "Definition of Done," and Example Mapping makes the "implicit" things "explicit." This aligns with what Kent Beck said about Stories and the 3 Cs of Stories: Card, Conversation, and Confirmation.
You talk with the business, hear their stories, and write them down on index cards—that’s a promise for future conversations. The business then decides on priorities. Next, you dive into the selected stories, having detailed conversations to understand them thoroughly. After that, you write the acceptance test scenarios, which provide the confirmation for the story.
Before moving to Acceptance Tests, I believe a User Story Map is required. It builds a shared understanding among the team and it also helps prevent the problem of building the wrong thing and decide on the scope of MVP. This way, we move fast not by writing code faster, but by eliminating the building of the wrong things!
Exactly. Acceptance Tests are a very objective, binary, black-and-white way to express "Definition of Done". It's about explicitness through examples. We've turned something vague ("Conversation") into something clear ("Confirmation"). Examples force us to go from general (unclear, multiple interpretations) into something specific (clear, single interpretation).
It's good that you pointed out the need for User Story Mapping before Acceptance Tests. Indeed, the sequence is:
(1) Build the right thing
(2) Build it right
(1) Build the right thing - User Story Mapping helps us nuild the right thing. Based on our understanding of the user's journey and what tasks they need to accomplish, we can map User Stories to steps within that journey. We have a holistic view of the user, big-picture thinking.
(2) Build the thing right - Example Mapping & Acceptance Tests help us build the thing right - in terms of behavioral correctness, i.e. building something that functions correctly. This is where we get into the nitty-gritty details of expected behavior. (Of course, correct behavior is just one aspect of building the thing right, there are other dimensions such as maintainability, performance, scalability, security, etc.)
Hi Valentina, a product manager here. 👋🏼 I think the problem you're describing it so acute, I've seen it many times. Adding detailed acceptance criteria with examples to the user stories definitely helps ease this.
I'd even go some steps further. I think what truly helps to achieve shared understanding in the product team is involving developers already in the discovery phase. It doesn't mean they have to take part in every user interview, etc. But I've seen it significantly helps in achieving a team-wide understanding of what problem we want to solve and why. Then ideating solutions together (devs, designers, product) also result in better solutions.
By the time we write those acceptance criteria, the whole team has a better idea of what we want to build, for who and why.
What do you think about this process?
Yes, absolutely! It’s a great summary, Valentina! 😊
100% agree. The process is:
1. Understanding the problem, e.g. through user interviews. The is crucial, because if we skip this step, if we don't understand the problem we're solving, if we try to solve the wrong problem, then our solution is useless, we're then wasting our time. Yes, we should start with this, rather than jumping to the solution. I've had good experiences that, where possible, developers be part of some of those user interviews, to understand for whom they're building the software.
2. Specifying the solution, together, by formulating the system requirements. Everyone (PM/PO, Developers, QA Engineers, UX/UI Designers) should co-create the solution, because multiple minds are better than one. For one problem, there is a multitude of solution, and through this collaboration we try to choose the optimal solution, one that satisfies the business problems and minimizes development effort. Follow the Card -> Conversation -> Confirmation. Ultimately, the Acceptance Criteria are the confirmation, they are a precise formulation of the requirements through examples.
3. The team can then convert the Acceptance Criteria into Acceptance Tests which is the first part of ATDD cycle, so that ultimately what they build satisfies the Acceptance Criteria.
4. After we release the product update to users, we get feedback, we discover if we understood the problem or didn't causing us to repeat the process above based on feedback, and that's the continous cycle.
How do you usually help teams respond when the PO says “this isn’t what I meant” after the feature’s already built?
By writing Acceptance Criteria in a testable way, and aligning it with the whole team - the PO, Developers, and QA Engineers, so that everyone is on the same page regarding what we mean. This needs to be done before we start implementing a User Story.
Yes, the Acceptance Tests give you the "Definition of Done," and Example Mapping makes the "implicit" things "explicit." This aligns with what Kent Beck said about Stories and the 3 Cs of Stories: Card, Conversation, and Confirmation.
You talk with the business, hear their stories, and write them down on index cards—that’s a promise for future conversations. The business then decides on priorities. Next, you dive into the selected stories, having detailed conversations to understand them thoroughly. After that, you write the acceptance test scenarios, which provide the confirmation for the story.
Before moving to Acceptance Tests, I believe a User Story Map is required. It builds a shared understanding among the team and it also helps prevent the problem of building the wrong thing and decide on the scope of MVP. This way, we move fast not by writing code faster, but by eliminating the building of the wrong things!
Exactly. Acceptance Tests are a very objective, binary, black-and-white way to express "Definition of Done". It's about explicitness through examples. We've turned something vague ("Conversation") into something clear ("Confirmation"). Examples force us to go from general (unclear, multiple interpretations) into something specific (clear, single interpretation).
It's good that you pointed out the need for User Story Mapping before Acceptance Tests. Indeed, the sequence is:
(1) Build the right thing
(2) Build it right
(1) Build the right thing - User Story Mapping helps us nuild the right thing. Based on our understanding of the user's journey and what tasks they need to accomplish, we can map User Stories to steps within that journey. We have a holistic view of the user, big-picture thinking.
(2) Build the thing right - Example Mapping & Acceptance Tests help us build the thing right - in terms of behavioral correctness, i.e. building something that functions correctly. This is where we get into the nitty-gritty details of expected behavior. (Of course, correct behavior is just one aspect of building the thing right, there are other dimensions such as maintainability, performance, scalability, security, etc.)