The art of Story Telling

User stories are an essential part of Agile software development but what really are User Stories? In this post I will try to demystify User stories.

Mike Cohn in his excellent book “User Stories Applied” gives us a definition of a user story as the one which “describes functionality that will be valuable to either user or purchaser of a system or software”. Thus a typical example of a user story would be “As a registered User of website I want to buy products online”. Here a value for the user would be an ability to buy products online.

A user story is written in a typical format like As a ….. I want to … so that … although it must be pointed out that it is not a requirement to write the stories in this format. Ron Jeffries gave us the 3 Cs associated with these User Stories viz. Card, Conversation and Confirmation. The card refers to the expected functionality in not too detail form but coupled with conversation those details are determined and confirmed before that story is picked up by a team member for development. Conversation need not be happening just before the story is picked for development but as part of development process till the story is completed. The conversation around a user story means that there is a high degree of collaboration between the team members resulting in increased shared understanding which is most valuable for collaboration.

As the stories are added to the product backlog at some point they will need to be brought into a sprint for development, but how do we know if they are “ready” for a sprint? A popular way to decide that is following INVEST criteria for user stories. INVEST is a mnemonic based on
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Through conversation happening on a regular basis and especially at backlog refinement sessions these stories are refined based on the above criteria to ensure that they are ready for the upcoming sprint for development.

One of the criteria for a user story to be Ready for development is “Small” which determines whether that story will be complete in half a day to two days by a developer. If the team thinks that it is not feasible for that story to be completed within that period then it may be required to split that user story.

Richard Lawrence in his post suggests that a story is split based on these guidelines

• If a story is based on a workflow then breakdown the workflow steps as individual stories
• If there are variations to business rule specified in a story then each such variation can be used to split the original story
• Sometimes a major effort is needed upfront to support variations in functionality to be implemented, so that part can be one story and variations can be split into smaller stories
• A complex story can be split by determining on its simplest form and then adding other complexities as part of other stories
• A split can be based on variation of data the story acts on
• A story may need to incorporate different interfaces for user input
Deferring non-functional requirements to other story / stories
• A split can happen on operational activities

Further reading

10 Tips for Writing Good User Stories

INVEST in Good Stories, and SMART Tasks

Patterns for Splitting User Stories

Standing Up

One of the rituals of working in Agile environment is daily stand up activity that happens typically at the beginning of a day where team members come together for approx. 15 minutes and plan for the day’s work. That’s correct; the main purpose of the daily stand up is to plan the work that each individual member of the team is aiming to achieve during the day. By way of the planning, the said member also expresses any impediments that may potentially prevent the work being completed.

By specifying what a person is trying to accomplish during the day, there is an underwritten commitment made by that person towards the team. It would be wrong to think that the commitment is for the benefit of the Scrum Master because this stand up activity is not a traditional status update meeting, but instead its purpose is to foster the shared understanding between the team members. It also helps to manage the inter-dependency, if any, between the team members’ activities helping in increased collaboration.

Not all the daily stand up meetings are effective though, so below is a summary of things to watch out for and ways to address them

  1. Team members talking directly to Scrum Master

    Scrum Master is a mere facilitator for this activity and his/her interest is in understanding any impediments that are in the way of each members scheduled daily tasks. One way to avoid this common thing from happening is for a Scrum Master to stand slightly away from the team members and avoid any prolonged eye contact with team members as they provide an update.

  2. Absentee team member

    Sometimes a required team member is absent from the daily stand up, this is fine as an occasional exception but a persistent pattern of this absenteeism needs to be looked at considering that the team member is missing out on a daily collaboration activity. Talk to the person to understand the reasoning of the absence and work out a solution. The objective being to avoid the blame game but instead focus on the benefits of being present and collaborate.

  3. Stand up taking too long to finish

    This may not be that big an issue if the stand-up goes over a few minutes. One of the reasons this may happen is due to team members getting into too detailed discussion over a certain issue. When this happens consistently though then it is important to remind the team members to be focused on the 3 main questions that they are expected to answer and any follow up discussion can happen immediately after the stand-up is over as not everyone will be needed for this discussion.One of the very popular ways to keep the discussion short and focused is to use a soft toy or a light weight ball as a token which gets passed from one member to another as they provide their answers to the questions.

  4. Waiting for prompt

    Sometimes team members need a prompt before they start talking, it is completely unnecessary. Passing the token (a soft toy or a ball) avoids this issue as the person who catches the token then gets a chance to talk. If you are not using “pass the token” then at first quickly inform the team not to wait for the prompt and remind them about self-organisation.

  5. Rambling on

    Some people like to talk a lot, this is good but not necessarily good from daily stand up point of view. A quick reminder for them to be focused will avoid the issue. Also having a running time and a rule suggesting that no one talks for more than a certain amount of time will help to keep the person on track. Another way to tackle this is by using a technique called “walk the board” where a person can talk about a story / task that is being worked on in a more focused manner.