Monday, 21 November 2011

Daily stand up meeting

One of the aspects of scrum that is often poorly executed despite its simple nature is the daily stand up meeting.

The daily stand up meeting is a brief stand up meeting designed so team members can provide progress updates to the team in a quick, efficient manner. Here is the basic format:

  • Daily, 10-15 minute status meeting – keep it short and sweet
  • Same place and time every day – encourages routine and rhythm
  • Standing up – encourages people to keep it succinct
  • The meeting is usually facilitated by Scrum Master, but in practice it can and should be facilitated by any team member
  • It is not a meeting to report progress to the scrum master – people should report progress to the team.
  • Chickens and pigs allowed (Guests are welcome to observe but if you’re not invested in the outcome, then please stay silent)

Focus on these three questions
      What did you do yesterday?
      What do you plan to do today?
      Do you have any blockers or impediments

Focus on progress
  • Scrum master should share a burn-down chart/burn-up chart/ kanban board so team has visibility of progress
  • Focus individual updates on progress against stories (e.g. I am about half way through this story, there is about this much left to do). Going into too much detail about how you are implementing it will bloat the scrum meeting. By all means raise problems and explain why a task is taking longer, but keep the focus on the progress.
  • Take discussions off-line if you feel a need to discuss a technical implementation, environment problems, release strategies etc. Be realistic! You can't resolve all these things during the scrum meeting. Identify the need to discuss the issue and then get together and discuss it after the scrum. 
  • Move cards on the board – this gives the feeling of progress and associated positive mood
  • If possible, each team member should move the cards they are working on, this gives them sense of ownership on their stories
  • The scrum meeting is not the place for:
    • technical implementation discussions
    • in depth environment discussions
    • release planning discussions
  • Don’t make a habit of interrupting others. Everyone deserves an opportunity to provide their update without being interrupted.
  • Don't treat the stand up as the only time of the day when you can raise issues or talk to your team mates
  • No mobile phones! Let’s face it, no-one is that important that they cant put the blackberry on silent for 15 minutes
  • The whole point of the stand-up meeting is to provide a quick, efficient progress update
  • Discussions can happen outside of the stand-up meeting.
  • It is not the only time of the day when you are allowed to talk to your fellow team members
  • Straying off topic wastes time for others in the meeting who may not be interested in the issue you are discussing in depth.
Chill out!
The stand-up meeting shouldn't be a battle and it doesn't need to be a strict regime of following the scrum rules to the letter of the law BUT you will find that being disciplined about the above "Dos & Don'ts" will keep your meeting under 15 minutes and will probably allow you plenty of time to ask occasional environment/ release/ implementation questions without wasting other people's time.

Last Tip: 
If you have issues with too many people talking at the same time in the stand up, you can use a ball or some other object to pass around in the scrum meeting. Only the person holding the token can provide an update. This ensures 1 voice at a time and has the added benefit of increasing people's consciousness that they are under the spotlight, thus encouraging more succinct, less chatty, updates. Some teams pass the ball around in a circle but passing randomly increases people's attention levels (I could be next!). The best stand up meetings I’ve been in have had fun speaking tokens (a toy monkey, a foam pig), and are thrown/ flung/ hurled in a random order. The worst, most boring stand ups I’ve attended have been where every participant provides an update in turn … zzzzzzzzz.

Tuesday, 8 November 2011

Why User Stories?

As a ... developer
I want ... well written requirements with clear acceptance criteria
So that ... I understand the functionality I am being asked to build, I understand the value of building it & I know when I am finished building it.

When an organisation switches to using agile methodologies, one of the most often asked questions by analysts and developers is “Why do we have to write user stories for everything?”  I’m sure that nothing irks a business analyst more than having to convert their beautifully crafted requirements document into a backlog of user stories.

Even when teams are in the flow of using stories as currency and have accepted that all functionality needs to be specified in user story format,  the tendency to disregard or misinterpret the INVEST principles is ubiquitous. Having a ‘bad’ user story can result in confusion, waste and inefficiency.

In general you’ll find scrum masters espousing the INVEST principles and the simple “as a, I want, so that” format. Story writers will often try to stick to these principles but through inexperience or lack of understanding will omit important elements or not fully understand WHY a principle is important.

In this article I try to impart some of my experience of writing and using user stories to highlight WHY they are a valuable part of the agile process and also try to put some clarity around the INVEST principles.

Let’s start with the basic format.  

As a ...
I want ...
So that ...

This is a very basic template, but it’s basic for a reason. Keep things simple, don’t overcomplicate the requirement. A user story describes a basic unit of functionality. Sticking to this format is not being pedantic; there are very valuable reasons for each section

Why specify the "As a ..."?

Developers need to know who will use this piece of functionality. By specifying the user, we remove doubt. This eliminates those irritating, post-development discussions such as "It was supposed to work for user type X only".

  • If we don't know who we are building this story for, i.e. the end user, then why are we building it? Is this functionality really required? As a scrum master if my product owner cannot answer this question then I will challenge whether he can save the project time and money by omitting it.
  • Multiple user types are specified. To keep user stories small and to avoid complexity it is advisable to have only one user type per story UNLESS the functionality is the exact same for each user. If the functionality is the same, then you can simplify by stating “As a .. user of the system” or something similarly generic that suits your model. When I see the word “AND” in the “As a ..” section it automatically sets an alarm bell off in my head.
  • “As a Product Owner” is not a valid user type for this section. We should not be using development teams to build features from a product owner’s wish list unless they are justifiably needed by end users. Better uses here would be “As a logged in user”, “As a guest user”, “As a system administrator” etc. etc.
Why specify the "I want ..."?

This is the actual requirement. What do you want to do?

  • “I want this AND that”. Try to avoid the use of the word "AND". If you need to say "AND" then question whether you should break this up into multiple stories. Is the “AND” bit another unit of functionality?
  • Verbose descriptions are not needed here. This should be a succinct statement of what the requirement is. If you cannot provide a succinct description then you may need to think about what the requirement and clarify the need that is to be satisfied.
Why specify the "So that ..."?

Why are we building this piece of functionality? If we cannot capture the value then why build the functionality? What need is satisfied if a development team builds the feature you are requesting?
Particularly in a team with limited resources this is the most important part of the story. This should help product owners prioritize requirements.

·         If you find you cannot fill in the "So that" section, then you should seriously challenge the story and whether or not it should be worked on.


“This story is done when ...”
A user story should have clearly defined acceptance criteria. This enables the story to be tested and enables a developer to know when to finish developing. It’s ok to flush out these acceptance criteria as part of the “discussion”. Remember, a story is a promise for a conversation, and every story should have a conversation between the developer and the requestor.

These are very useful for testing. Specific journeys such as:
“go to page x, enter username/ password, click login, click accept disclaimer, verify text exists on next page, verify new feature exists etc.”

As these scenarios are of specific interest to the tester of the story, it is often best for a tester to work on flushing out these scenarios in collaboration with the product owner and also maybe the developer.
  • A brain-dump of everything you know about a requirement does not a good story make! It only serves to reduce the clarity of the requirement.
  • There is a feeling that writing a requirement in user story format takes more time, it doesn't. It takes more thought!
  • Sometimes it may feel artificial to force a requirement into user story format. If it does, then talk it through with someone and see if they can phrase it better and verbalize the value more clearly. Persisting with the format will result in clarity of requirements and will highlight the value of the work we are delivering.
The INVEST principles

In my experience, a well-written user story follows the INVEST model. You don't need to tick all the boxes, but the more the better!

“Independent, Negotiable, Valuable, Estimable, Small, Testable.“
  • Independent - One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult.
  • Negotiable - A user story is negotiable. The "Card" of the story is just a short description of the story which does not include all the details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.
  • Valuable - Each story has to be of value to the customer. A story should deliver value independently of all other stories.
  • Estimable - The developers need to be able to estimate a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of clarity in the requirement or lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
  • Small - A good story should be small in effort, allowing the team to complete many units of functionality in a given iteration
  • Testable - A story needs to be testable for the "Confirmation" to take place. If you can't test it then you will never know when you are done.
To sum up, I recommend following the INVEST principles and I also think that the basic user story template is so crucial to a simple, easily digestible user story. Writing user stories shouldn’t be viewed as chore or an additional tax on a project, but an absolute necessity for a development team to deliver successfully

Stand up art :)