Month: March 2016

What makes a great user story

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

User storyUser stories are a great way to describe what a future system or solution should be able to handle, and they are great to span the communication gap between UX-designers (user experience designers) and the developers.

User stories are bundled in what is called epics and are broken down into sub tasks.

The user story format.

The user story should always be written using a specific “formula” or syntax. The format is as follows:

As who, I want to what, so that why.

If a user story is put in this format, you are sure to give developers a good insight into what is really wanted and you will make sure that they don’t start doing a lot of guessing once they start developing.

Just compare the two following user demands for a musical festival website. The two demands basically ask for the same thing but one demand is written as a user stories and the other isn’t.
Demand 1: “You should be able to print directly from the website”.
Demand 2: “As a festival visitor, I want to be able to print the musical program, so that I can mark the bands I want to hear”.

The first demand is very open – What should be printable? Is it the tickets or a plan of the festival grounds and maybe we should include the entire website menu? Maybe it is the address of the festival office that is important or a receipt for the purchase of the tickets?

Let us say that “Demand 1” is written 3 months prior to it being implemented and then believe me – No one can remember what “print” was meant to cover (not even the customer).

The user story answers all these questions – We know exactly what is to be printed in what format and by whom. AND it is all documented, so if several months passes before we start implementing, then we will still know exactly what we wanted when we did the user story.

The flow in creating a great user story.

There are three steps and three different focus groups which needs to give input if you want to have a great user story and if you want to create a good flow once the development starts. These groups are the future users, UX designers and the solution developers.

The short version is that the future users put their demands in epics, the UX-designers will break these epics down into user stories and the developers will break down the user stories into sub tasks which they will start implementing.

An example:
Let us say that the users create an epic called “Login”, which they describe as follows “The website should support logins, so that classified information can be shared with employees of the company while they are on the road”.

This epic is then broken down into one or more user stories saying:

  1. As an employee, I want to register as a user, so that I can login.
  2. As an employee, I want to login, so that I may access the classified information.
  3. As an employee, I want to be able to reset my password, so that I can get a new one if I forget the old one.
  4. As an administrator I want to be able to delete a user, so that I can make sure they can no longer access the files when they leave the company.

And so on…

The user stories are handed over to the developers who will then break them down into subtasks of no more than a day’s length. This could look something like this;

  1. “As an employee, I want to be registered as a user, so I can login”:
    1. Create login form including username and password,
      Estimate: 0.5 day.
    2. Create userdatabase tables,
      Estimate: 0.5 days.
    3. Set up MySQL database,
      Estimate: 1 day.
    4. Setup certificate for HTTPS,
      Estimate: 0.5 days.
    5. Order certificate for HTTPS,
      Estimate: 1 hour.

Once the breakdown into sub tasks is done, you simply add up the time expected for implementing the user story, which in this case would be 2.5 days and 1 hour.

The same pattern is repeated for all user stories related to the epic “login”, and the entire budget for implementing the epic is presented to the customer/product owner for approval.

A little tip – Use “accept criteria’s”

A little tip – When doing the user story, you should put in about five accept criteria’s related to the user story. This will help til developers to pinpoint exactly where to put their efforts. However, accept criteria’s will also help the users and customers to check if what they requested 6 months ago has been implemented, and it will eliminate scope creep as well.

An example of accept criteria’s for the user story regarding printing the festival program which we looked at earlier could be.

  • Accept criteria 1: The entire program should be printable.
  • Accept criteria 2: The program should fit the paper size available in the printer.
  • Accept criteria 3: Pictures of the performers should be included if they are available on the website.
  • Accept criteria 4: The Festival logo should be in the top right-hand corner of each page printed.

Imaging how simple it is to test a solutions by simply checking the accept criteria’s before you can sign it of to production.

Reporting to your Sterring Committee

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail
Steering Committee reporting
Steering Committee reporting

Reporting to your steering committee might be the one thing that you should always give your full attention. These are the people who expects you to handle their project and make sure that it is steered safely to target… And if they do not trust you, they might replace you. Therefor you should never try to hide risks, issues, budget problems or milestone changes. Get it out into the open so that they know you need their help.

Your report has three functions that you should always keep in mind;

  1. It should give the steering committee a complete overview of the state of your project.
  2. It should give the steering committee the ability to focus their efforts on project issues that needs their attention.
  3. And it should give the steering committee the ability to make calculated decisions in regards to the projects issues.

When to report?

If possible, you should send a report to the steering committee once a week – You can help yourself and make it a reoccurring event in your calendar.
You might have steering committee meetings once every two week, once every month or similar, all depending on your project, but you should always make sure that the steering committee receives the report at least 24 hours before the next meeting.

Sending the report at least once a week, means that you need to keep it short and effective. No one will read a 10 page report if it is send every week… Besides, you would end up doing nothing but writing reports. Instead, keep your report to a maximum of two pages and whenever possible communicate in KPI’s and bullet points.
Things that you need to include but can’t be kept at two pages should be put in as an appendix – E.g. a timetable, burn down charts, financial reports etc.

What should go in a steering committee report.

So, what should go in a report. Well, there are seven things you need to focus on as a minimum. These are:

  • Executive summary.
    Make sure the report always have a KPI summary at the top of page one, to give an overview of where there might be problems that needs the committee focus. E.g., budget changes, changes to milestones and so forth.
  • Progress.
    Here you should make an indication of resources spent to date, how many resources are needed before you are done and how this adds up to your original estimates. Let the steering committee whether or not you are on track.
  • Budget.
    Present a statues of your current budget situation and your expectations – calculate how much is spent to date and add it to the remaining budget for completing the project. Afterwards compare it to the budget previously approved by the steering committee – Do you lack funds then let them know.
  • Timeline.
    Only put in a description of the changes that has been done to the timeline since your last meeting – And keep the entire timetable as an appendix to the report. If no changes has been done since the last meeting, you should put in the report “no changes done” and leave the timetable out.
  • Resources.
    Does the project have the right resources? Do you need a person with a special set of skills? Do you have enough resources to complete on time? (e.g., you have 3 developers but need 7 to make the deadline). Also, let the steering committee know if you have resources that aren’t useful to your project, so that they can be put to other tasks and doesn’t drain your budget (e.g. you have five digitale designers but only need one of them part time).
  • Risks.
    Here should go the five biggest threats to your project, which you have not handled yet. There might be several more risks to your project, but you should only put in the five most pressing.
  • The project managers concerns
    This is where you as a project manager can rise concerns that you can’t really relate to the focus points above – E.g., the steering committee needs to meet once a week instead of every month or maybe lack of input from the accounting department on expenses is becoming a problem in your reporting etc. In other words , this is where you can tell the committee things that affect your project, but is not a direct risk to it.

Download a report template here >>>