The session details from the programme are below
| Epics & User Stories | How to break user needs and the user journey in to deliverable product “requirements”, in consumer language. Introduction to Agile/Lean/Scrum methodologies and how to best work with technical teams. From here, the design stream will move from sketching to software used for mobile development. | Priya Prakash, Andrew Harder | 4/10, 6.30 (Thurs) |
[notes in square brackets are my own additions, so blame me]
This course is not about learning to write requirements, it’s about the designer view of them.
User stories describe the way your product appears to the user, and how it fits into their life.
[it may be worthwhile explaining the hierarchy that surrounds requirements and User stories.
User requirements are bound into Stories, a User story typically defines a set of action for the user to achieve a given thing. Much like a Use Case in UML.
Then there are epics, Epics are collections of stories into a bundle.
So for example you may have a user story that is to “login and check balance” that is part of an Epic called “account management”
Further if you need to group in more than one way some folks use a “Theme” as a container for epics and user stories, this is useful when a product or service has quite different facets to it’s functional landscape.]
Eg I want to fly to x, and to arrive at a specific time.
[in order to make sure the User stories are properly aligned] Get her user stories from the “persona”, “needs and journeys” to help you flesh out the details, and not just the obvious.
[indeed it is the details that will cost all the over runs and difficulties, because there is a devil in there]
When looking to make sure that your requirements are a good set it is wise to make sure you study the competitors and substitutes. [substitutes belong services that could replace yours, but are no direct competitors, so for the flight example a Train service or similar]
In particular walk through the user journeys to pull out the requirements, and make sure there are no sections uncovered.
In the case of a student timetable, look at the use of a paper timetable, and how the teacher would communicate changes to it.
With the user journeys, look at the take always, as these are the key points that were recognised.
Also ensure that the break points are covered.
Collect the requirements in one place eg prodpad.com or sprint.ly these are monthly paid for services.
Tie the stories to the requirements, tasks, defects and tests.
[this is called traceability, the idea is that it is possible to trace a connection from an error back up to the requirements, so that changes can be made accurately and precisely.]
So now we have a long list of requirements and user stories, what else would there be ?
Well does it look good, is it on brand, will it be attractive to your target audience.
Non functionals like performance, responsiveness, accessibility etc
admin functions and training needs.
[Non-functional requirements or NFRs as they are also known, are those requirements that define the product but are not derived from the system’s behaviour as perceived by the user. Typically these include security, performance, scaling, backup-restore and so on]
Remember that there is a strong halo effect of good visuals, as users will impute goodness onto the rest of the app.
One thing that the long list of requirements will not deliver is simplicity, and good user experience that comes from this simplicity, therefore refine your requirements.
“The Simplicity Shift” is a good book on product requirements and how to manage them.
E.g. “unfeatures”: for example make sure the data is right, eg make sure there are no towns in the sea [reference from the recent debacle of iPhone maps which has many errors here in the UK]
a quote from the Simplicity Shift
This has happened often enough that I call these things unFeatures, which are common things that go wrong with the product and, which, initially, are never put on to a feature list. These problems are handled, usually badly, at the end of a product when the first working prototypes start making these issues glaring and no longercapable of being ignored.
Hunt for these unfeatures in these kind of areas of use:
- setup or first use
In apps the first use is important, as so many of the learning problems need to be resolved in first use.
- Most frequent tasks
Most frequent must be rock solid, or users will be turned off quickly
- Sense of place
Sense of place, eg breadcrumbs etc, because users can get lost.
- Complex data sets
Make the simple simple and it’s ok if the hard is hard
Eg on the iPhone to set the flight mode the switch is on the settings home screen, but changing the time zone is four levels deep, because it does not need to be simple.
Of course not all requirements are equal to each other, in terms of the order in which they should be tackled,
and setting priority is difficult so use a more scientific approach, and here is a suggested formula:
Priority = business value + user value + use frequency
This means you score each requirement on these factors, and then sum up each requirements score for the 3 factors, it is this total that provides the final priority.
[This is fine for user stories, however you may also want to give weights to the Epics and themes, so that you can either parallelise them or indeed serialise the epics and/or themes]
Then consider a forced distribution to prevent everything being high priority [because it is amazing just how much of the requirements set will end up being high priority, in my experience we’re talking over 75%]
However make sure that you maintain the minimum viable product, coz you have to do this, priority or not, further consider the minimal desirable product, as this is the best outcome early on.
So for example you might want to make a cake, so start with a cupcake, then I’ll move up to a full cake. The small cupcake is tasty, complete and users want them.
Ie you can iterate and grow from the minimal viable through the minimal desirable towards the full product.
Ensure that your requirements are able to deliver delight and performance, and don’t spend all your effort in your hygiene factors. [hygiene factors are those requirements which are necessary, but perhaps do not deliver the actual user experience you want, for example being able to change the font is nice, but may not really be required for an early beta.
Look up the Kano cheat sheet, and use this as another prioritisation plan.
Remember that hygiene factors are not things that users buy, eg toilets on a plane, you don’t select an airline based on the number of toilets there are in the plane. The Kano model is designed to help you separate them out from what users do buy.
Once you get a list of the requirements then you must put them into a roadmap, and keep the roadmaps simple,
What we are going to do now, next and later. That’s it three columns. This is very good for sprint or similar types of process. Any more complexity [than a rolling three release view, one release per column] will prolly just cause more confusion than it solves.
[so in short make sure you cover the ground with your requirements, but them sort them out into the minimum desirable product, and be form with the feature creature and do ot let it whisper more exciting ideas in your ear.
Make sure that the requirements that are not just hygiene are given priority and the most clarity, as these are what will delight your users.
Manage the requirements, to allow for tracability, for re-sorting and for rolling into a roadmap ]
All Things Mobile 
Posted on November 12, 2012
0