User Stories And Acceptance Criteria In The House
User Stories and their Acceptance Criteria as the base of implementation work is shown by the example of drawing a house in this post.
User Stories
User Stories are commonly used in context of Agile software development but that’s not a limitation. Acceptance Criteria will allow you to determine whether or not you have completed the implementation of a User Story. They are usually a list of 3 to 5 bullet points stating what must be achieved in order to deliver the User Story. Additionally a User Story can have optional information or constraints attached, however this will not be dealt with in this post.
For software development to be efficient it is essential to stick to the User Story and Acceptance Criteria that you implement. Everything you implement that is not requested might result in waste or unnecessary efforts.
The Exercise
Here is an exercise that you can use for demonstrating the side effects of gold plating and implementing more features than actually required. This exercise can be used in retrospective meetings and other sessions with space for learning.
What you need to do for the exercise is pretty simple, draw a house. Ideally on a flip chart or something similar. In case you don’t like houses, draw a car or any other thing you could imagine the exercise works with. For this post we go with the house. Keep the house simple. This will make the exercise clearer and causes less distraction for participants. The picture below is an example that I’ve used previously.
Now that you have drawn the house, you basically have your User Story. The drawing shouldn’t be visible to participants yet. Write down your User Story that you will later read out to the participants. To complete the User Story you will have to add Acceptance Criteria describing features that the house must have. The list below shows what I’ve used with the house in the picture.
- a front door
- one window on the ground floor
- two windows upstairs
- a pointed roof
Remember to limit Acceptance Criteria to a maximum 5 bullet points.
Now your User Story together with the Acceptance Criteria is complete and you could actually invite participants and start the exercise. Put some pieces of paper and pens on the table and explain the exercise, so that everyone knows what to do. Set a time box between 10 to 30 minutes, that should be sufficient. Then read out the User Story and Acceptance Criteria in one flow. Participants will probably ask questions, that you have to answer in order to clarify the User Story. Once they know what to do, they can start thinking of how to do it and start drawing. Don’t worry, each drawing will look different and you will have lots of points to talk about.
A few minutest before the exercise ends, remind everyone to finish drawing. Then reveal the house you have drawn in the beginning and go through the User Story and Acceptance Criteria. Verify whether the participant’s houses meet the Acceptance Criteria and the User Story would be accepted or not. While doing this you can point out all the impacts of the participants work. This can be mapped to software development projects directly with examples from daily work.
Here are 3 examples that I’ve got on the Acceptance Criteria I’ve stated above:
Example 1 shows the the participant has paid some attention to details but didn’t meet all Acceptance Criteria. Thus the drawing will not be accepted and would need rework.
Example 2 shows a house that meets all Acceptance Criteria plus some extras that haven’t been mentioned in the User Story. This can go well in real projects but holds a strong risk of making extension of features or implementation of new features difficult. The chimney for example was not requested. In case the house owner decides to put solar panels or a window on the roof in the future, it would cause additional effort to remove the chimney. Further more this change costed time that someone pays for.
Example 3 also shows a house that meets Acceptance Criteria but has a carport attached to it as well as a tree beside. Again features that were not requested, which means extra costs and effort for something that has not been asked for. In software development projects this may be a problem since the time spent on non-requested features was already planned for other features.
The following list of reasons why gold plating or implementing features based on assumptions should be avoided, will help you to start some conversations:
- it causes more effort and cost for quality assurance
- it could contain bugs and prevent the User Story from being delivered
- it extends implementation time, that causes additional costs
- it might make it difficult to incorporate adaption or extensions in future
- the results might not deliver the value that the User Story was written for
- etc.
More insights may come out of this exercise and you are invited to share them in the comment section below.
After you are done with the exercise and follow on conversations, make a final statement to remind participants of the lessons from this exercise for daily work. I personally find this exercise very helpful and it often turned out to be an eye opener for conformity to requirements.
Let me know how this exercise worked for you. Subscribe and share if you liked this post.
Reads:
- User Stories Applied: For Agile Software Development
- User Story Mapping: Discover the Whole Story, Build the Right Product
- User Experience Mapping: Enhance UX with User Story Map, Journey Map and Diagrams
Sources & Links
Leave a Reply