The User Experience Team of One

Research and Design guide focusing on pragmatic strategies for user research and experience testing for those with limited resources byLeah Buley.

 

Design Patterns

Design patterns : elements of reusable object-oriented software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

UML 2.0

Learning UML 2.0 by Russ Miles and Kim Hamilton.

The Art of Agile Development

The Art of Agile Development by James Shore and Shane Warden.

Scrum

Scrum: a Breathtakingly Brief and Agile Introduction by Hillary Louise Johnson and Chris Sims.

• about
• methodology
• news
• other
• tools

The life of a Story

It all starts by talking through the user journey with the stakeholder. The stakeholder may want to offer his customers online control of their accounts to (initially) cut the costs associated with the print and distribution of account statements. The conversation may go something like this:

1. Analyst. How do you intend to inform your users of the online service?
2. Stakeholder. We intend to send out emails, and letters, and advertise in national newspapers.
3. Analyst. If I received an email, how do you think that might lead me to register?
4. Stakeholder. Well I guess there would be information about the new service in the email together with a means by which you could navigate to an online site, where you would be able to register…

From the above dialogue with the stakeholder your are starting to see user journeys forming. There will be many more journeys, and you should strive to keep keep them simple, and not get bogged down in too much detail. At this stage you are simply trying to identify the big steps and all of those (actors) involved. It is from user journeys that user storys will emerge.

The following diagram illustrates a journey for a new customer online service. There is a call to action to grab the users attention, followed by registration and finally some form of confirmation of the completed journey e.g. online and via email, letter or SMS.

 

Sometimes it helps to provide context to User Stories so that you can understand the part they play in the wider context of the project by building a user story map – a better version of a product backlog. Building a user story map helps to focus on the big picture – the product as a whole. This approach is explained beautifully by the AgileProductDesing.com blog, entitled “The new user story backlog is a map“.

Story Writing

Why do we use stories?

• It’s a simple, easy to understand way to keep requests succinct, accurate (but not too specific), and with an eye on the business value.
• Because the format is so easy to understand, customers easily grasp the nature of a story, and how to write them.
• It shifts the focus from getting a request to actually understanding the request and the reason for it.
• Describe relatively small pieces of functionality that are easier to implement well.
• Makes it easier to estimate accurately.
• Makes it easy to identify the real business value.
• Are written in business language so all users can understand and prioritize them.
• Are written in business language so developers and QA can understand them.
• Avoid implementation detail – forcing an implementation often results in business value not being achieved!

Writing a good story

• Use the “As an X I want to Y so that Z format”
• Always write it from the user or business perspective.

As a credit app approver, I want to view a person’s bank balances so that I can gather info for a credit approval.
As Paul I want to view the top news stories for the day so that I am informed of the most current and interesting news and can show off to my friends.

• It should starts and end at the UI (we call this vertically slicing a story)

It is never ‘Record transaction’ or ‘Add field to DB’

• Keep it intentionally vague enough that’s it’s obvious more information is necessary.

Do not give detail – it gives a false sense of accuracy or completeness.

• Keep it implementation free

It is not ‘I want to call this method to…’

• Follow the INVEST principle (independent, negotiable, vertical, estimable, small, testable).
• It has consistent granularity at each level of story (theme, epic and iteration level).

Characteristics of good stories

Stories should follow the INVEST principle.

• Independent

Can be developed on its own.  Avoids dependencies on other cards.

• Negotiable

It’s not a contract – the details are decided upfront and they’re negotiated during development if needed. A good story captures the essence of what’s needed, and is flexible .

• Valuable

When possible, stories should be vertical slices of real functionality (think of slicing a cake – you want all the layers, but a thin enough slice so you can eat it all) Valuable to the role (user/actor)  (As an X).Valuable to the business (I want to Y). Has clear and valid business value (So I can Z) . Think in work flows and actions.

• Estimable

Stories are elements of planning and must be estimable.
They need to be understandable enough to be estimable.
Consistency in the granularity of stories helps accuracy in estimation.

• Small

Large stories are hard to estimate and hence to plan.
They often hide big ticket work.
Should fit within one iteration.

• Testable

Stories should be obviously testable when you first read them.
They should be testable through the UI.
They should be possible to automate.

Characteristics of good stories, Independent

• They can have handshake dependency on other stories but on their own you should be able to describe them as an independent entity.
• Combine stories if they can’t stand alone, or break them out if they contain dependencies that will block the card from getting done in a single iteration.
• As a guide stories should be written around an action to get the right level of independence (and help testability).
• Story Anti-Pattern

Get invoice information from the Invoice database

• Story Pattern

As an Accounts agent, I want to create an invoice so that my company can request payment from the Customer

•  Explanation

“Get invoice information from the Invoice database” doesn’t really stand on its own. The customer really wants a printed invoice so they can send it to the customer. Combine it with the card that says ‘Print invoice’ (I’m sure it was there). If getting the info from the db and printing all of it on the invoice is too much in a single iteration, split the card vertically. Get a subset of information from the db, get it to print, and then play another card to get more information, print it, until the invoice is done.
Never split a card horizontally (don’t just ‘save to db’ or ‘retrieve from db‘). There are many reasons, but the best is that cards should have business value and be showcase-able to the customer, and horizontal cards usually don’t / aren’t. A good way to know if you’re slicing horizontally is if you don’t end up on the UI at the end of the story.

Characteristics of good stories, Negotiable

• Keeping stories negotiable really means leaving room for flexibility. They should be succinct, but they shouldn’t be precise.
• Leaving room for what the detail of the story is gives the customer, analyst and developer yet another reason to have a conversation – what does the story really mean?
• Stories that sound too precise give a false sense of accuracy – e.g. if it has so much detail, it must be exactly what we need to do. That isn’t and shouldn’t be the case. It’s a placeholder for a conversation and for negotiating the details when you it gets close to development.
• Story Anti-Pattern

Display summary results for a patient including date, result status and results indicator (normal or abnormal).

•  Story Pattern

As a physician, I want to see summary results for a patient so I can quickly see if the results are normal.

Notes: Actual info to display needs more analysis.  Will include date, result status and result indicator (normal or abnormal).  There are no other integration points.

• Explanation

The anti-pattern actually reads pretty well, doesn’t it?  You might pick up this story and think it’s close to be ready for development.  But that wasn’t the case on the real project.
The story actually required the display of a lot more information than what was described on the anti-pattern, and that data needed quite a bit of analysis.  The story actually went to three iterations because the team was forced to replay the story twice in order to get all of the result information they needed to display.
Stay away from adding detail to the story.  Use the notes to write down what you’ve learned and make it clear that isn’t the whole enchilada.

 

Characteristics of good stories, Valuable

• The story should add value to the business – it should be related to something the business needs to achieve, and is often action oriented (like allowing a customer to order an item from the website).
• Business value is relative, and some cards will add more value than others, but as you’ll see in the below examples, when we say valuable, we’re saying focus on what the story should be helping accomplish. Do not focus on what the story should be ‘doing’.
• Story Anti-Pattern

Turn font red if payment is overdue

• Pattern

As an Account Manager, I want to see a visual indicator on the customer’s screen of any invoices that are overdue so that I can send an overdue notice.

• Explanation

There are many things wrong with the anti-pattern. The most obvious is that we don’t who needs the font red or why. It may not even be that they want red font – it’s just what the system currently does.
Do the following to help:
a) Isolate the functionality needed (e.g. see a visual indicator for overdue invoices).
b) Identify the role(s) that are interested in the action (often roles have different needs).
c) Identify the reason (the business value) for the request.

This enables you to:
a) Get consensus on what indicator everyone wants to see.
b) Allows you to understand why the indicator is needed.

Characteristics of good stories, Estimable

• Story Anti-Pattern

As a cashier I want to take payments via credit card so I can make a sale.

• Story Pattern

Story 1a: As a cashier, I want to take payments via American Express so I can make a sale.

Story 1b: As a cashier, I want to take payments via Visa or Mastercard so I can make a sale.

•  Explanation

The anti-pattern is just too big to estimate. Any number you throw out there isn’t going to tell you anything. Spike the story a bit (analysis spike) and take a look at the interfaces.
Notice this story has 3 credit card types but only 2 stories. Turned out the Visa and Mastercard interface were so similar there was little additional work involved in getting Mastercard working.
This is a point toward consistent granularity. The team could have created a 3rd story ‘Take payment via Mastercard’ but at the master story level it would have thrown the granularity off. It made more sense to roll them up and break them down at the iteration level if needed later.

Characteristics of good stories, Small

• Breaking stories into the right level of detail is fairly easy if you follow a few guidelines.
• At the master story level, small means being able to T-shirt size it. If it’s not T-shirt sizable, it’s too big. Break it up.
• At the iteration level, a story shouldn’t span more than a single iteration. If it does, break it up.
• When you break up a story, break it up vertically, not horizontally.

Do not think horizontally (e.g. get the persistence layer working). Think vertically.
An easy rule of thumb is if there’s a UI, the story should start and end at the UI.

• Story Anti-Pattern – Multiple Stories in One

Process payment from customer.

• Story Pattern – Multiple Stories

a) As an Accounts agent, I want to enter basic payment information and have it displayed so I can verify it has been recorded correctly.
b) As an Accounts agent, I want basic payment information processed centrally and see it on the mainframe so the customer gets credit for the payment.
c) As an Accounts agent, I want the customer’s payment to show up when I search the existing reporting database so I know whether the payment will display on their invoice.
d) As an Accounts agent, I want the customer’s payment to display on their invoice so they know we have received the payment.

• Explanation

Large stories are often stories that are actually many stories in one.

Break them up into smaller vertical slices of what’s actually needed.

Remember to get the right level of granularity – don’t break them up too small.

Characteristics of good stories, Testable

• There are two levels where a story must be testable. First, the original story (As an X, I want to Y so I can Z) must be specific enough so that even without writing detailed acceptance criteria, you’d understand the happy path to test the card.
• The second level occurs if the acceptance criteria are added to the story itself (on the back of the card, in the story spreadsheet, somewhere). The project is usually small and the cards aren’t complex enough to expand into a narrative. The acceptance criteria are simply added to the story and it goes into development.
• For both levels, what’s written should be possible to automate – no fuzzy logic, no esoteric distillation of the requirements. Anyone that reads it should be able to take what’s been written write solid tests.
• Anti-Pattern

Get external link types

• Pattern

As a user, I want to see the links to external websites that I have saved for myself display on the home page when I log on, so I can easily do research using these links.

• Explanation

How do you test ‘get external link types’? This story put the developers and testers in quite a bind. Rewriting it with a business focus made it clear what was required.

 

Acceptance criteria

• Acceptance criteria are one liners about what the functionality should or should not be doing.

It is often written in the ‘given when, then’ format.
Also popular in business logic format.

• Use the SMART (Specific, Measurable, Achievable, Relevant, Time-boxed) guidelines to compile them.
• A story is not a story without acceptance criteria!

Why? – because you are then never sure when you are done

• Styles of Acceptance Criteria.

The Given When, Then format. Given display of the EOD Mismatch report screen, when user selects particular report, then user is able to monitor and correct matching workflow of the trades.

• The business logic and assumptions format.

The below reports are available for users that have view security permissions:
Report X.
Report Y.
Report Z.
Reports pull real time data from System A via System B.
Trades that display as matching on the report have been matched in the trader and sales blotter.
The US cannot see UK reports and vice versa.

• Narrative Template

Background / Context (if needed). This section should have the SHORT background or the context. It should tell the reader of where and how the functionality will fit in the overall picture and how it will change/enhance the existing system or add/expand the functionality of the proposed system. This also gives the reader a background into the business process that is realized using this feature.
Screen Shots. Put screen shots here if editing or adding screens / fields.
Assumptions. Any assumptions you or the team are making.

Mocks & Stubs

Martin Fowler explains what is meant and achieved by testing with mocks and code stubs. Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object. See also Steve Freeman’s blog on the subject.

Copyrighted Material ©