How do I write a good user story?

1. Consider the user

By practicing user centered design you face a greater chance of understanding the exact requirement implementing this feature will provide. So make sure that the user story is written from the perspective of the end user in their language to achieve exactly what it is they want to achieve.

Its worth considering the difference between:

Implement a secure access 4 pin unique code which is digitally encrypted and expires after 15 minutes.

and

I need to make sure that the content is secure but easy for people to use, they have a pin number for our other systems could we use that and make sure they have to re-enter it if they walk away from the tablet.

In the first example its not clear to anyone why and what the outcome will be of implementing this. However in the second description it is clear why this is necessary and what the outcome will be. This makes it clear for everyone involved.

2. Keep them short and simple

Just enough to make it clear to everyone, no one appreciates reading too much content which could be re-formatted and presented in a way which is clear, precise and accurate. KISS!

3. Quantify the effort involved into units of a day or week

Once we have a good user story you should be in a position to work with a developer (if you are not one) to provide a robust estimation of the work involved (beware of risks and unknowns). Approach this task with a view to identifying the days and hours involved. If the task is smaller than a day consider batching a few other short tasks together. Remember to consider what else might be involved and point out that this is the time to conduct the implementation of it only.

Once you have a collection of user stories you should expect to implement between 3 and 6 user stories per a week. Of course this varies if you have more developers buts its a reasonable way of monitoring the scope and complexity of each user story if this becomes wildly wrong in reality.

4. Ensure you can verify and prove it

Once its been implemented you should be able to revisit the user story and test it. A good user story is one which when revisited you can verify that its been achieved.

Its worth considering the difference between:

Make the web site usability easier for users to navigate.

and

Adjust the user interface so that a prominent start here, navigation bar and favourites menu can be easily and consistently located on every page through-out the website.

Defining the user story this makes it easy to test and therefore prove it has been achieved.

User stories are a great way of capturing understandable information in a format more than just the analyst can work with but as Scott Sehlhurst points out you must remember to iterate and communicate often with the client to iron out the details.

Resources:

A short and rough guide to user stories however if you want to see a more in-depth explanation check out this book (it really is the 101 of user stories):

User Stories Applied: For Agile Software Development by Mike Cohn

More about Mike Cohn who is the owner of Mountain Goat Software.

Andrew Fuqua also has some good things to say on  SCRUM user stories

** Update ** And finally I found some good info comparing User Stories and Use Cases by Scott Sehlhurst

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The next time someone says to you they follow agile, scratch the surface and find out what that means. Something like:

1. How have you managed stakeholders through your flavour of agile?
   Releasing software every couple of weeks allows you to demonstrate features as they are developed. With the demonstration enabling the stake holder to offer insight and changes which can be discussed and adjusted as easily as possible because its demo’d by the developer and is fresh in his/her mind.
2. Explain how do you release new functionality?
   Working agile involves developing features not modules. Features are approached with the intention of accomplishing a single small task. The by product of a feature approach is that you expect the software to change in the future as more features are included, this can cause regression issues so a strong testing framework which is automated is essential.
3. Explain how do you respond to change?
   Change is the norm so we must get used to it and comfortable with it. Because there isn’t a lengthy analysis, design, code, test, deploy cycle it should be easier to incorporate adjustments. Releasing often and developing features rather than modules enables you to modify the system more easily in the future. Refactoring tools have also come a long way in some languages to support the developer in this task, applies to Java / C#.
4. Explain how do you approach new code integration?
   Expect to hear the phrase ‘continuous integration’, which is the practice of integrating each developers code together on a regularly schedule. Bonus points should be given if they can demonstrate and practice real continuous integration which would require multiple integrations per a day.
5. Which flavour of agile do you use?
   OK I won’t list them hear as its an evolving space, personally I like BDD (Behaviour Driven Development) but I also still have many happy code bases following TDD.

Hopefully this short list of questions will give you a good basis for evaluating if the individual really does agile or just excuses the fact they don’t do documentation, design and/or testing of what they produce.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

You’ll need a capable browser like Google Chrome or modern Firefox to view.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

If we consider the accessibility specifications and tools available it is quickly apparent that flash is lacking in this regard. Understood the paper work is in order from both Adobe, the browser manufacturers and main assistive software providers. But have you actually tried it?

In this 2 part series I will comment on first hand experience developing solutions to provide accessible flash and contrast this against the information available from webAim who have taken great care to survey validated users on their use of flash websites.

Finally I will provide some bold recommendations on how to navigate this difficult field to improve the user experience for all concerned. Please don’t take my approach as correct it stems from years putting large amounts of content together and trying to meet clients opposing requirements.

Screen Design & Presentation

Lets start by considering the quick, obvious and beneficial to all wins: Organise your screen design so that the layout is easy on the eye, visual ques and information is well positioned, logical and correctly marked up.

Flash: Strong Support

How: By organising the materials on screen in a clear, consistent and meaningful way is easy in even the oldest of flash players. Careful selection of colour palettes is essential and avoiding the use of text on graduated backgrounds is good practice. Other requirements including ensuring that any content presented to users is not time bound, this ensures that those who need longer to read are not disadvantage.

Oh and please please no blinking, moving, animated text.

Scaling

With more recent version of flash comes the introduction of scalable vectors graphics support. This allows content to be scaled to any size without loss of any quality. For those requiring accessibility options taking advantage of this feature is desirable. Unlike providing text only resizing controls the entire flash content is resized. This approach ensures that the use of scroll bars, text overruns, pagination are avoided.

The Timeline

Flash operates very differently to traditional web development. HTML is largely static and has no support without complex programming to support a timeline. A timeline allows content, actions and experiences to be triggered in response to a time event occurring.

As a result this can provide engaging content however it can also severely limit the accessibility capability.

So what to do…

Consider the impact your timeline events will have on users who may need longer to take in the content. Perhaps the use of a pause, rewind/replay controls will provide all that is required to ensure that the widest range of users can access the content.

In the next session I’ll continue the discussion and look at keyboard accessibility, closing down of the ‘open web’, navigation and interactions. Also included will be the use of video and audio and how to handle screen readers and where there may be the case for alternative formats such as separate accessible formats such as a essay document.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.