Last week I delivered a webinar talking about building good user stories. We had nearly 200 participants from five countries. Thank you to everyone who took the time to register and participate.
I was unable to respond to every question as they were asked in the chat window, and we had to stick to the limited time we had available.
Fortunately we were able to record the questions so I could try to answer them after the event. Here are a sample of the questions with my answers. Where more than one person asked a similar question I have only recorded it once, and there are a few questions that I can’t answer publicly 🙂
There was one question about the work being done on the Agile Extension to the BABOK(tm) – is the working group only looking at techniques or at the broader framework?
We are examining all aspects of how Agile techniques impact on all aspects of business analysis activities. Keep an eye on the IIBA(tm) website for more details as the work progresses.
When we were talking about the Vision Box someone asked: Would going into detail like logo and other not destract the purpose of the vision meeting?
The logo and other details are not intended to be high-fidelity or precise, they are meant to provide a hook for the conversations and creation of shared understanding of the vision. Don’t get bogged down in the exact placement of graphic elements, fonts and Pantone colours – focus on the essence of the vision elements.
The discussion about Personas generated a few questions:
Could you please advise what tools and techniques we should use to ensure that we have identified all the personas?
There is no magic trick to this one, I’m afraid; you need to conduct a stakeholder survey and ask lots of questions – who are our customers, users, clients, victims, other interested parties. A question that I’ve found useful is to ask every participant in the workshops “who else should we be talking to about this thing”.
Should a regulator/ govt law maker be a persona?
In my experience external groups that provide constraints rather then functional aspects generally don’t warrant detailed personas (but they might be referenced in stories such as “as the compliance officer I want …so that we don’t lose our banking license”) if they will actually interact with the product then they deserve a persona and profile.
The Epic Model also generated a number of questions:
A few people questioned the “one person” aspect of the definition of an Elementary Business Process.
The description I use is that an EBP is something done “in one place, at one time, by one person” and it should achieve a specific result for the business. It will normally be part of a chain of events that result in the delivery of value for the consumers of our product or service. There are some EBPs that are not “one person”, often these are “small team” activities where a small group of people are working together to do a job. Some EBPs have no human interaction – these are fully automated activities. Examples of these two types of activity are – replacing a large window in a building (“replace a window” will be an EBP for a glazing company but some windows are too big for one person to replace alone) and the overnight charge for staying in a hotel (undertaken at say 2am every morning by a computerized process).
Someone questioned the amount of detail in the epic model – should this not be left for the detailed user stories?
Here I resort to the consultant’s standard answer “it depends” – if you are able to identify the primary objects and start to understand their relationships at the Epic stage then do so, but be very careful not to get bogged down in the detail. In my experience adding the objects at the Epic level helps clarify the overall understanding of the scope of the work to be done without increasing the amount of work and time needed at this stage in the overall process.
There were a few questions specifically about user stories and acceptance criteria.
Do user stories supplement or replace functional specification documents?
In my experience user stories are a far better tool than functional specification documents, especially when used in this Progressive Elaboration way. Most of the requirements are likely to change over the duration of a project so trying to lock down the detail early on simply results in more wasted effort as we make the changes later in the project.
User stories are deliberately kept light early on, and the acceptance criteria are only added to the story on a just-in-time basis, typically this is done a few days ahead of when the story will be worked on by the technical team. What goes into the acceptance criteria depends on what the team need – it could include screen wireframes or mockups, low-fi data models and other structural aspects. I feel you should always include the test design criteria, ideally in the Behavior Driven Development format.
Someone asked What is the difference between Use Cases and User Stories?
A Use Case is a combination of scenarios about how an actor will interact with the system, normally written in a structured “Actor does … System does …” format. A single use case normally includes multiple paths through the system (primary flow and the alternatives/exceptions) and is often built with the intent of defining the full interaction early in the project. This is far too detailed to be used early in the project.
Each row on the Epic Model could be a placeholder for a Use Case, and that model can be used to provide a list of Use Cases if you are using that approach.
A User Story is much smaller than a Use Case and the two are quite different. A Use Case covers multiple interaction scenarios, whereas a User Story could cover a single scenario for using the resultant system.
Alistair Cockburn says that “a user story is to a use case as a gazelle is to a gazebo”
When should the Acceptance Criteria be added to the User Story?
As late as possible, but not too late 🙂 The concept here is the “last RESPONSIBLE moment“. There are some things which we need to consider early on in the project – typically these are the Architecturally Significant Non-functional Requirements that are very expensive to refactor if they are not built in to the product from the beginning. The trick is to consider just enough and just in time without undertaking a lot of wasted effort.
Again – thank you to everyone who participated. The audio recording and copies of the slides can be downloaded from the Software Education website.
Posted by Shane Hastie