Tag Archives: Agile analysis

Turning stories from good to great

Ask how stories are written in an Agile or Scrum environment, and you will inevitably get the “As a …, I want …, so that…” bog-standard, cookie-cutter answer.  But ask yourself this, is that all you write in a story?

User stories in the Agile world is a means to achieving a goal in software applications.  The umbrella definition, if I may call out, is a placeholder for a conversation.  We say stories are a shorter, leaner, lighter version of capturing a business requirement, whilst never, ever, intended to replace a good conversation.

This is a perfect prelude to a modern myth: that user stories do not need to be written with the standardised business requirements document format, with use cases, UML / sequence / state diagrams, compatibility matrix and all their glory in the old world…. which means they do not need to be written with the same level of rigour.  Anyone who could muster “As a .. I want ..” can therefore write user stories.

In truth, rigour is thoroughly practised, if not more so than requirements in the traditional sense; the rigour and discipline are actually found not in the documentation format but in the content.  Having written user stories for years at ThoughtWorks, there are a set of principles that really help me to turn stories from good to great.

1. Get your story right

As an editor,

I want to create drafts for my articles before publishing,

So that I can show them to the editor-in-chief for tweaks before my articles goes out.

I have lost count on projects where stories are incomplete.  How many times have you seen the “so that” part missing?  It is often the most difficult part to express in the entire story, so many people just leave it out.  Do not make this mistake.  The story format is laid out like this for a very good, real, reason.  It is so difficult to get this part right, let alone having this part, because it forces the author to think hard about WHY this story needs to exist, the very reason for being.  It is justifying why the company should spend its money on developing this over another story.  Which means that if there is no real reason for it to be there, it will be de-prioritised or deleted altogether.  However if you omitted this part, there is very little telling on the true value it delivers.  It will just be a list of wild wishes mixed with legitimate wants and needs.  It also encourages behaviours like “whomever shouts the loudest gets the most stories that they want” — ending up in this situation is a sad place to be, really.

Another pet-hate is seeing “As a user” for all hundreds of stories.  Do you have only one user?  Really?  Just one type?  No personas whatsoever?  … I will gracefully leave this out for another time.

2. The unwritten rule of what goes inside

I always have at the ready The List, regardless of what domain I am working in.  The List contains the cornerstones that tell you whether your stories have the minimum sufficient amount of information to express what you want to do, for the development team:

  • Story: As a, I want, so that
  • Description
  • Assumptions
  • Technical notes
  • Out of scope
  • Acceptance criteria
  • Estimate
  • Priority

Going through The List really spells out whether you have gathered enough information to begin development.  It is no longer acceptable to write half-baked ideas and masquerade them as requirements, under the Agile or Scrum label.  Please, don’t blame Agile or Scrum when you are really just lazy; being Agile does not mean we have any less attention to detail.  It is focusing on the right level of detail in the right places at the right time.

3. Choose your words carefully

As you are writing less, really mean what you say when you say it.  Make sure you are using the same language as the domain and not adding another hoop for the team to jump through.  When you are writing stories, make sure you are referring to the terms correctly and consistently.  Been using the word graph? Don’t switch to say chart mid-story.  Even if they mean the same or similar things to you it would not always be the case for someone else.  I have a few more examples:

  • Picture vs. Image vs. Illustration vs. Diagram vs. Graphic
  • Description vs. Content vs. Blurb vs. Stub vs. Paragraph
  • Number vs. Digit vs. Character
  • Table vs. Chart

Same goes to when you are talking to QAs, developers, product managers and stakeholders.  Be aware that terms and names are used for mapping out the domain model, lives in the codebase as well as unit tests, functional tests and end-to-end tests … so being consistent will only help everyone understand what you mean clearly.

4. Use acronyms sparingly

Do not build the barrier to communication higher by putting in loads and loads of (even commonly known) acronyms.  One person’s understanding of CMS, CRM, GDP, SAT, SIT is quite different to another.

5. Convention over OVER-complication

In life and in story writing, use plain English as much as possible, strive to use this rule as often as possible.  There is no better way to put this.

Whether you like to admit it or not, no one wants to read reams and reams of waffle when they are really looking for the boiled down facts — so show only the boiled down facts — and show it clearly.  Lots of analysts grow frustrated or disheartened, or both, when they found out no-one was really reading their documentation.  Worse still, many miscommunication and misunderstandings stem from the fact that implied requirements are hidden in paragraphs of text when they should be clearly spelled out line by line.  Be explicit, unambiguous and concise in your words.  Adding unnecessary terms to things can only confuse people and it is everywhere: words like framework, repository, structure, XYZ manager when you are naming features may be intelligent-sounding but really build towards the fluff that people learn to disregard.  Shock horror, not (!)

I hope this is useful.  As with most things in a collaborative environment, ask for feedback from your peers if you are unsure of the right level of detail; you never know, a little feedback goes a long way in the world of continuous learning : )


Agile Brazil 2011 talk slides

Two weeks ago Danilo Sato and I had spoken about the techniques on how to define a big chunk of feature into something that can be consumed by the development team, at the Agile Brazil 2011 conference in Fortaleza.

The motivation behind this is to get people involved in development team, from the immediate team members to product owners and beyond, to think about how to articulate and express feature wants and ideas in a form that will best deliver the most valuable goals in an iterative way.  Splitting large chunks of features into stories has been one of those topics that very few people have mastered, and for the most part the precise techniques are largely unknown.  For this talk we used a worked example to demonstrate how to slice and dice a high-level feature in multiple ways that help address different priorities, which could be business driven or technically driven.  We then shared ways that we use to help stakeholders keep track of stories that had been split as a result of delivering features iteratively.

The slides for the talk, “Slicing and dicing your user stories“, is now available on SlideShare:

Feedback and thoughts welcomed.

The necessity to adapt

One of the more exciting things about being an analyst at ThoughtWorks is that you get to be at projects of very different business domains.  On one project, you could be in an investment bank, sitting in a room next to the trading floor; or, you could be studying the differences between 5 different designs on presenting a retail trade show, and you are within earshot of a fashion shoot.

Such differences in the physical working environment scream of an indicator of how you may need to adapt your ways of working.  Adapting your ways meaning that you need to tweak how you communicate and deliver your ideas to your audience so that the message can be heard in the correct way.  Same everywhere else, same for Agile.  The specific method of execution needs to be tailored to the specific needs, wherever you are.

Some of these so-called differences are apparent, for example, working environment or physical space that the project is located, others are more subtle and is picked up through interaction.  As analysts, we not only learn about the kind of tools that help facilitate people, but in what situations you would apply them and how.  By acknowledging these differences, it may help you to identify the best possible approach you take whatever project you are in.

Here is a sample of things that have helped me through various projects.

Adapt your tools

Capturing requirements on the fly from day zero is a big part of analysts.  Just because you are capturing requirements, it does not have to be done in one rigid way.  At some point, you may be doing this on 4″x6″ index cards, it may be on Excel if you are faster at typing, or you might even be doing this on Mingle.  Choose the method that is best for you and the situation.  What’s important as an analyst is that the essence of the story and the ideas behind the conversation are being captured.  You can do this quickly as long as you can recall such conversations or the high-level idea, because it allows you to go back to the people who first came up with them and continue with those conversations.  That is the main goal of your actions.

For instance, when you are in a time-pressured scenario such as story writing workshops, you could not afford to spend all your time in one afternoon discussing a handful of stories only (if you did that your inception would probably last for months, and would lose all the other valuable conversations that you could probably have had instead).  Scribble things using pen and paper, carry a fancy Moleskine to not lose the scraps of drawing (or the notebook even).  What about the white board and taking photos on your smart phones?  Present it on your iPad?

Adapt your methods

How you present your captured requirements is just as important as what you have written.
In a previous project, the clients were extremely visually oriented people and do not respond well to lists, documents or narratives well.  Or anything that consists of reams and reams of text.  In these circumstances you either go ahead and do it anyway, running the risk of your clients losing interest in the meeting, or you think of other methods of communication that will capture your audience and convey the same message well.  This resulted in facilitating a prioritisation workshop with images drawn on  cards.  I sometimes capture conversation points on a mind-mapping tool — simply because visual tools speak louder to me and I love being able to present this to the client.

Adapt your own interpretation to the local domain

Not literally the local language (though I have done this), but adapt your vocabulary to the client’s.  Immerse into their world.  Use their domain language to break the communication barrier, and you will find that you would not be fighting so many battles based on trivial things such as “We call it Iteration and you call it Sprint”, and instead focus on solving real world problems.

Continuous improvement and continuous learning

Agile is not a prescribed set of methods that, once utilised step-by-step, it will solve all your problems.  It defeats the name and defeats the point, really.  The trick is not apply any single tool so blindly that you hinder yourself from spotting a different way to solve a problem.  I have seen far more dangerous practices / restrictions that have been applied to projects or departments that, in the end, did more harm than good.  Just because you do stand-ups, you are not Agile (you are still practising waterfall methodology everywhere else).  It is not a label associated with a practice.  It is the underlying principles of Continuous Improvement that so many overlook; of knowing that you are not here to adhere or conform to the set of rules, but to continuously look for a better method of doing things; constantly asking yourself this question, knowing that you will inevitably find those improvements that will outdo and outsmart your previous ways.

It is not about coming up with the smartest, sophisticated system and let monkeys run wild with it; it is actually putting the smartest people you can find in any system and trusting them that they will come up with the smartest system for themselves.