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.)
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.)