In the first post in this two-parter we looked at how to introduce Agile Methodology to your clients. In this second post we’ll zoom in and focus on User Stories and outline a few tips to help you successfully utilise them.
User Stories are well accepted as being a simple but effective way of devising feature requirements and their subsequent tasks for development.
Here at Brightec we love working with our clients to create the best User Stories. Here are some of our top tips for how to best introduce them to your clients:
It's quite simple really, if it’s User Stories you want from your client, then just introduce them to that. Don’t start explaining how they are going to fit within your burndown charts or velocities, time boxes and retrospectives.
It’s similar to when I meet up with my wife and her work friends. She works in education and as soon as they start talking about NQTs in KS1 using kinaesthetic PECS techniques for a level 2 learner (I don't know either) I’m looking uncomfortable and edging towards the door. It’s the same for those that don’t work within software development or Agile frameworks.
We have a specific and often odd way of talking (let’s just admit it ok folks) and it can make those who are outside of our world feel confused and out of their depth.
When explaining the need for writing user stories we usually start off with something like:
‘One of the most important components of creating a service or software is understanding who the user is, what they want and what they need. If the user isn’t understood properly, then the service or software can fail regardless of how aesthetically pleasing it is, how stable its code is or how many features it has. To do this we use stories to understand the user and their wishes.’
A user story is a short description of a feature from the point of view of a user. It contains:
Lots of teams use the template: As a < type of user >, I want < some goal > so that < some reason >.
Most people when starting with the concept of User Stories often don’t realise quite how difficult and time consuming they can be. It’s good to let them know upfront that a good set of User Stories can take a considerable amount of time.
As an example, one of our larger clients, who are very experienced in Agile, usually block out a whole week for writing user stories for new versions.
It can seem like a lot to the client, but explaining that they are the most important tool the developer has for getting their product produced as they want it should hopefully bring them round to putting the time and effort in.
It’s good to let the client know how we are going to extract User Stories. It can be done by just going straight to wireframes, designs or specifications and working through each section bit by bit.
Although this can be helpful later on, I have found that if we start in this way we can quite quickly just end up rewriting the existing document if the client hasn’t totally understood the concept of User Stories.
Storyboarding is a great tool for very quickly presenting the scope, reasoning and idea for a project. It doesn’t have to be big just a quick intro to the project so that you can very quickly visually:
A great article for using storyboards within user stories can be found here:
Once some high level User Stories have been written, it’s then that going through the documentation can help to add smaller stories or detail.
As with any Agile based organisation we are constantly re-evaluating and finding ways to improve what we do. The tips above aren’t a 'how to', but more a collection of our thoughts that we hope will be useful for understanding how to use User Stories.
There are also some great resources freely available and below are a couple of our favourites:
Don't miss Part 1 of this short series here: http://www.brightec.co.uk/blog/agile-methodology-and-our-clients-part-1
Search over 300 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!