This topic addresses the following questions:
- I have read not to include what the end user wants to see in user stories, but we are. Where do you specify what fields are required by the user in a user story? In high level acceptance criteria?
- Within a given Agile user story, what is the best approach to determine and write up acceptance criteria using the Given When Then format?
- What are the rules and principles to achieve success here?
- Also, are there other formats (other than GWT) that are common or work well?
As per the user story standard, I write stories in the familiar 3-part format, and I like to write the acceptance criteria in the “given-when-then” format, e.g.
Given that I am a registered user, when a submit a form, then the system … does something
The advantage of this method is that it tells the story in a more easily relatable scenario and follows the goals of the end user (which we derive from the process).
I also think that it is perfectly okay to write straight requirements for the acceptance criteria – whatever works for the situation and your team.
I don’t believe there is a wrong or right way, just what is best for your organisation. There is industry ‘best practice’, and then there is ‘good practice’ which fits your organisation. I am a big believer in good practice, but like you, I need to know the fundamental rules and principles before I go adapting anything.
Using the GWT format, when I get to “then” I describe the details of the system behaviour and page elements, etc, in bullet points underneath.
This has it draw backs as it can get quite long and difficult to consume the information within the story, and they say you are not meant to include the details in the story.
However, some developers love very detailed documentation… so it has its advantages too.
You could pull that additional detail out of the GWT statement and just show it in wireframes and supplementary notes or annotations on the wireframes.
I almost always create wireframes too. They only need to be very simple – not graphic design masterpieces. I have used Gliffy a lot. The tool is basic but does the job – and it is a plugin to Confluence or it can be used as standalone tool.
I think that you could work with your team and get agreement on the best way to describe your stories so that it meets the communication needs of your business stakeholders and the technical team. This would be your definition of success.
I don’t think the Agile gods will strike you down with lightning if you do things differently.
In fact, I think the gods would nod with approval if you took the lead and defined success this way:
- Irrespective of format, the story clearly represents the business requirement and goals of the end user – and clearly communicates to the business SMEs.
- The acceptance criteria also clearly communicates the conditions, rules and boundaries for the given story. This, again, is irrespective of the format you use and how you express the level of detail.
- Establish clear agreement with your team what information is required for each ticket, the format of the story, the format of the acceptance criteria, and any other information such as data flows, wireframes, and any other visual models.
- Ensure clear agreement with your team on when this information must be available for them to perform their respective jobs, i.e. development, testing, etc.
As you know, one of the underlying principles of Agile teams is that everybody works towards delivering the outcome, which means that we all pitch in and work across skills and traditional roles to ensure success, e.g. the developer can help elaborate requirements, the business analyst can help with functional testing, etc.
This way we don’t fall into the Waterfall approach if it is felt that all requirements need to be elaborated up front by the BA before it is received by the developer. We still need to keep the flexible team approach, but some structure will help eliminate some of the fumbling around and uncertainty.
Just back on formats, you could also try the feature driven development (FDD) syntax.
This format is especially good for also dealing with conditions that are not user facing (e.g. non-functionals and system constraints, etc). The syntax looks like this:
[action] the [result] [by|for|of|to] a(n) [object]
For example: Generate a unique 8 digit identifier for the application record.
I quite like the FDD approach as it deals with certain types of requirements that are a bit removed from the user, and the requirement doesn’t have to be forced into the story format.