A user story is not a detailed requirement. It is a reminder. A user story’s purpose is to remind us to have a detailed conversation … later. In some future Sprint Planning session, when we see the story, we will remember that we need to fully understand the story’s purpose and the expected outcome. We will have conversations with our customers and create tasks (and their estimations) to plan the technical work to accomplish the story’s purpose and detail acceptance tests (another kind of task) to specify the story’s expected outcome. I have to admit that in practice this process can be a little tricky for some domains. The user story is not always “OK to Go” the first time we remember to understand it. For example, the story “As a User I want to add a Patient to a service program so that standard protocols can be followed” brings up many questions. How does a service program enforce a standard protocol? What attributes of a Patient determine the need for a service program? What are the standard protocols? Do different service programs use the same standard protocols or different ones? This kind of information is not always “known” within a complex organization, especially if it is automated by a system targeted for retirement … and no one knows how the system actually works. Looks like somebody (a System Value Optimizer or a System Quality Optimizer) needs to do some research and (depending on the complexity) this research may take more than one iteration to complete. A good conversation would go something like this:
Product Owner: I want to schedule this story for Sprint 1
Team: Asks all the questions above of which the Product Owner does not have all the answers
Product Owner: OK. We’ll work on this one some more and have it ready for Sprint 2
Then while the development team is working on Sprint 1, other team members search out and gather all of the information required to answer the questions so the story can be planned with confidence for Sprint 2. Alternatively, the team could split the story and work on known parts during Sprint 1 and postpone the “unknown” parts until Sprint 2.
You can consider the strengths of the team to help make your decision. If a Strong System Value Optimizer and a Strong Application Architecture Optimizer are on the team, choose the second alternative due to the high probability of getting the information (system value) on time and getting it integrated into the next build (application architecture) on time. If both of these strengths are not present on the team, choose the first option and reevaluate the story for Sprint 2.
I found it more than a little awkward writing my last post as I tried to avoid roles names by referring to “someone who scores 15+ in Optimize < > “. I have a solution! Instead of “someone who scores 15+ in Optimize < >”, I will simply say they are a < > Optimizer. For example, I am a strong System Value Optimizer, Application Architecture Optimizer, Implementation Optimizer, Process Performance Optimizer, and Development Process Optimizer and in such you can feel confident that I will achieve excellent results (ER) in these areas.
If you haven’t taken the Optimzation Model Survey now is a great time. Thanks!
The Optimization Model case, Optimize System Value, was not included in the survey because of a lack of space in the questionnaire but a person that would score 15+ on Optimize System Value is someone who cares deeply about developing a system that accurately delivers requested business value and in so are often recruited for testing efforts. Because of this, you might think they would also score 15+ on Optimize System Quality but this is not necessarily true. One who scores 15+ on Optimize System Value, traditionally an analyst, is motivated to deliver a system that does what it is supposed to do while one who scores 15+ on Optimize System Quality, traditionally a tester, is not only motivated to deliver a system that does what it is supposed to do but they are also motivated (and sometimes more so) to deliver a system that doesn’t do what it’s not supposed to do. Is it possible therefore to have a well-functioning team without someone who scores 15+ in Optimize System Value? No, I think not. This strength may belong to a Product Owner, a tester, a developer, or even a ScrumMaster but it has to be present on the team if the Product Backlog has any hope of being a reliable input to product development. Someone who scores 15+ on Optimize System Value helps the Product Owner accurately represent requested business value in the Product Backlog and makes sure the user stories gathered are independent, negotiable, valuable, estimatable, small and testable – not a simple task. They also work with the Product Owner to create Acceptance Tests that determine the criteria that makes a developed user story acceptable. In other words, they are driven to do whatever it takes to make sure the system accurately delivers requested behavior.
Someone who scores 15+ on Optimize System Quality may also work with the Product Owner to create Acceptance Tests but they will also create additional test assets to make sure the system performs within acceptable parameters and is secure, reliable, maintainable, operational, etc. My experience has been that delivery of requested behavior is what makes a user story “done” and that these types of tests are done outside the Sprint boundary. But they definitely could be included in the Acceptance Test suite. I guess it is a matter of what individual teams consider “done”. As anyone who scores 15+ on Optimize System Quality knows, a system that can be compromised and/or rendered unusable adds no value to a business.