4

“Drawing a smiley: acceptance criteria”

 2 years ago
source link: http://oikosofy.com/drawing-a-smiley-acceptance-criteria/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

acceptance criteria” – Oikosofy

by Raquel Pérez

In this exercise we will work the need of asking questions to the Product Owner. The main aim is to define every user story as clear and complete as possible before starting working on it. At the end, we will analyse the acceptance criteria.

What can you expect to get out of this exercise?

Thanks to this exercise we may expect that the team will check the user stories carefully, analyse the acceptance criteria and detect requirements; these requirements could be from an environment to some images or other needs to get the user story complete and not being blocked in the way. One of the key points is the timing, we have to be used to analysing the user stories not before starting developing them but before compromising to develop them in the current spring; ideally during the grooming meeting.

This exercise is looking for encouraging the dialogue around the team.

When would you use this exercise?

This exercise is quite useful when you have recently started working within the scrum framework and your team is not used to think about acceptance criteria; what the user story implies, what boundaries should be set, think about possible blockers/requirements for the development and other questions that may arise from the Product Owner; he is the one who knows what generates the business value.

The main aim is to be as focused as possible during the development time as well as to ensure that what we are developing is the expected! Let’s answer every questions before starting. For that we need a deep understanding about what a user story implies.

How to do it?

This exercise is pretty easy to be implemented.

What do you need? You need, at least, 2 post-its and a pencil for each team member.

Where to do it? You just need the team to be sat down and ready to draw.

How to start? Ask the team to “Draw a smiley on their post-its” and give them 1 minute.

We assume that the team has not asked any questions about your expectations from these smileys. If they ask you questions, you can of course answer them. Then, you will have to adapt the exercise. I’d suggest checking whether every acceptance criteria are taken into account (see example of use story below), if not all of them are asked, just keep the exercise going, if they were all asked, add a new acceptance criteria! I give you an example at the end of the post.

Afterwards, ask team members to show their drawings. After everyone shows their artwork, you can ask them following: “Hadn’t I told you that I expected…” where “…” it is something that someone has included on their drawings, such as for example: You expected the smiley to have square eyes instead of circle eyes or you expected the smiley not to have hair.

Then, you ask them to iterate: Let´s draw a new version, the version no. 2 of their smiley; give them another minute. Feel free to answer any questions that may arise. The ideal situation would be when they ask you questions about expectation. There could be some questions related to smiley’s shape or shape of the eyes.

After a minute,  take a look at the version 2 artwork and check whether they met your expectations.

At the end, you will define the complete user story for this exercise; an example could be:

“As a (´smiley´) Product Owner I want (smiley) ´This particular drawing´ so that I can decorate my wall”

  • The head is a circle
  • The eyes are oval
  • The smile is curve down”

Conclusions: As a conclusion of this exercise we may point out the importance of asking before doing. In this case, the “waste” has been just 2 post-its and 10 minutes, however, on our daily basis the development of something that it is not expected would mean the rejection from the Product Owner, meaning this needs to change/be updated. We want to avoid working twice!

Rachel is a certified Scrum Master based in Spain. She is passionate about Agile and Scrum methodologies and enjoy working within a team environment.

If you have any questions related to this article, feel free to contact Rachel on Twitter @rachelLondoner.

Picture credits to: Rachel Pérez


In case you are interested in Agile Retrospectives I am at the moment preparing a 10 Days FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us: [email protected].


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK