Working with user stories in developing our products for the call center and mass notification markets has brought more focus to software development at Inova Solutions. When a user story has been defined, estimated, and prioritized, the development team can pull the story into a development iteration and begin work on it, with the goal of completing that user story in its entirety during that one iteration. This means each user story must be small enough to fit into one iteration’s worth of effort (usually one team of five to nine people working for one to four weeks). How we develop a user story to get it into shape to implement in a single iteration is the topic of this and the next posting.
At Inova Solutions, our Product Owners work with departments throughout the company, survey the call center and mass notification marketplaces, and visit customer sites to come up with new product ideas and changes to our existing suite of products. The Product Owner expresses market needs in terms of one or more user stories. For major new features or changes there will be an epic story, encompassing the entirety of the new product or major change to an existing product. The Product Owner then expands the epic into sets of user stories that describe the problem space that the new functionality will address.
Agile teams talk about the process for developing user stories in terms of the Card, Conversation, and Confirmation1. Different terms are used on different teams, but these three aspects of a user story are common in the agile development community.
Card – A high-level statement of the user story, including the user by name, a statement of the problem, and why the problem needs to be solved, usually in terms of what the user will be able to accomplish.
Conversation – The Product Owner and the development team get together to discuss the meaning, intent, and acceptance criteria for the user story. The product owner will elaborate on the environment and conditions surrounding the problem and will state the intentions and objectives of the users and customers of the story. The team will ask questions about the story and discuss approaches for possible solutions – but only in so far as to understand the user story; solutions and designs are not provided at this time. Often the team’s questions can lead to changes in the user story.
Confirmation – The acceptance criteria specify how we’ll know that the user story has been accomplished. When the acceptance criteria are verified as having been met, we’re confident that we’ve met the intentions and objectives of the story.
User stories are couched in everyday terms and in the business language of the user. This encourages communication between the customer and development teams. At Inova Solutions, our Product Owner acts as a proxy for our customers and is not a software engineer, so putting our stories into business language facilitates the conversations around user stories. There are also software testing tools that allow for automating acceptance tests in business language so the Product Owner can participate in developing the tests (for example, FitNesse2).
If a user story statement doesn’t encompass all it needs to be useful at the high-level, that will usually come out in the conversation. Questions will be asked that aim at putting the user story into context with the overall epic and the other user stories defined to meet the epic. If a question or its answer reveals that the user story or the current set of user stories is incomplete in some way, the Product Owner can clarify the user story at hand and/or add new user stories to the project. If the user story does cover the high-level need adequately but more details are needed, that, too, will come out in the conversation and more specifics can be added as acceptance criteria.
Next time, INVEST in user stories
1 Ron Jeffries, “Essential XP: Card, Conversation, and Confirmation,” XP Magazine, August 30, 2001
2 FitNesse (www.fitnesse.org)