Tag Archives: Agile

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 : )


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.

XP 2010: Kickstarting an Agile project

My XP2010 session proposal has been accepted!

The session is called Inception Workshop: Kickstarting an Agile project.  It is a workshop-based session to explore the tools used to initiate an Agile project.  This is an opportunity to not just talk about, but actually simulate a range of tools used in the context of a given business problem.  Often times you only get to hear about these tools & techniques, but just hearing about it is not quite the same as seeing it in play.  Aside from sharing what tools could be used, I am also interested in hearing the experience of other Agile projects, and how different teams initiate their projects.

Another different approach to talk about this traditionally analyst-led effort is that I will be co-presenting this session with Danilo Sato.  By looking at this from both an analyst’s and a developer’s point of view, we are able to present this topic from both technical and analytical perspectives.

XP2010 will be held at Trondheim, Norway. More details – for those who have registered at the event, it can be found here http://xp2010.agilealliance.org/node/5380.

What does an Agile analyst do?

At work, every now and then, there would be an email that goes round asking what the definition of a particular role entails, in our company.  Here at ThoughtWorks, this question extends to what this role also means on projects.  It’s all very well understood and defined for developers, architects, project managers alike, but what about analysts?  Recently we were asked to give a definition on such a role, when someone wants to join TW as a business analyst.  What do we say in answer to the question “What does an analyst do in ThoughtWorks?”

How do I describe what it is that I do?  I know I could spot one when I interview one, but how to tell others what definitions or criteria you have been using?  There is no obvious, prescribed way to distinguish what a TW BA “is”.  There’s no rule or precise formula.  Every one is different.  It’s more of an art than the result of a pseudo-scientific definition… but these are the cues:

Listening skills
.  There are many, many roles and personalities in a typical TW team who would offer advice / opinion / comments at the drop of a hat, so an analyst sometimes needs to take a complete reverse approach, step back, and listen to what the clients are saying.  This, as well as being a good note-taker (itself a major understatement) would help capture the vast amount of information throughout the project, from inception phases, to delivery, and handover.  People laugh when they hear the comment “BAs need to be good note takers”, and thought that well this is a common sense thing that every one can do well in; actually, it isn’t as simple as that.  Ask any team member what difference it would make if they are at the receiving end of a good set of notes vs. badly written scribbles.  Then ask a team member in a distributed project what difference this would make for them.

Understanding and appreciation of technology, without having the technical know-how as a pre-requisite.  BAs are here to help find ways to solve a problem, here to suggest and give educated judgement based on their previous experience and what their analytical minds tell them.  We need them to take part in discovering with clients what they could achieve, and help map the road for them.  BAs in principle are not there to tell you how easy or difficult it is to implement this feature this way or another.  We have our brilliant developers and technical leads for that.

Ask Why, and ask again.  Are they naturally inquisitive people?  Do they just take information at their face value, without questioning why things are done the way it is now?  We want BAs to not be order takers.  IMHO it’s a soul-destroying road to nowhere and diminishes your entire existence in the project.

Last, but not least, having the raw skills of naturally being comfortable working in any domain.  We do not want to hire analysts who can only flourish in one area, and wish to stick to one sector only.  Particularly in TW projects, for practical reasons, we ask analysts to be as adaptable in as many domains as possible.  From investment banks to trading floors, and media publishing companies to fashion houses, it should pose as no barrier that threatens a BA’s effectiveness.

Stop reading now if you think the role of Agile business analyst starts and ends at writing stories.

In a nutshell, Agile business analyst is not the same as Systems Analyst, Systems Development Analyst, Technical Analyst, and is still different to the Business Analyst you find in traditional software development thinking.  But of course there is so much more than just a name and a title.  As with this post in this blog, it is just the beginning.  In the meantime, what do you think an Agile business analyst does?