Tag: Scrum

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.

Roles and responsibility

Jan Schwaner
Facebooktwitterredditpinterestlinkedintumblrmail

the-broken-chain1Knowing who is who in your project is alpha and omega when communicating to your stakeholders, but more important is to know who is responsible for what – Call it your chain of command if you like, or who to turn to when things start to turn bad.

Below you will find a short description of the 4 roles, that is the minimum you need to assign to your project. There might be other roles and responsibilities that you need to assign, but the four roles below should always be assigned.

Project owner
So what roles should be assigned in a project. First of you need a project owner, who is financial responsible for the project – This is “The big dog in the kennel”, and he or she will be ultimately responsible for the entire project and its success. This person is the one paying the bills, and therefor he or she can ultimately add more resource to the project and save you if needs, change the scope of the project by removing tasks or maybe even close down your project if expenses are too high.

Project manager
The next in the chain of command is the project manager(s). There can be one or more project managers to a project, e.g. if you are doing a project for a customer, then there can be a project manager at the supplier and at the customer. The project manager(s) are responsible for the day-to-day management of the project, and they report directly to the project owner and the other stakeholders, including the steering committee. Reporting can include things like finances, progress, risks, deadlines and other issues – Basically what the steering committee and the Project owner needs in order to make the right decisions.

Product owner
The product owner is responsible for creating and updating the project backlog (which is the list of tasks that sums up your project). The product owner need to know his/hers product well enough to prioritize, update and maybe even remove items from the backlog. He or she is also responsible for creating the sprint backlog, which focuses on the tasks that is to be included in the sprint at hand and the upcoming sprints (see previous blog post on the Product owners rule in scrum projects).

Scrum master
A project (if agile) can have one or more Scrum Masters. The Scrum Masters role is to make sure that the day-to-day progress of the project is running smoothly. This role is normally given to one of the senior developers on each development team. It is the SCRUM master obligation to report any problems that the team can handle to the project manager and product owner, but also he or she needs to make sure that the development runs smoothly on the day-to-day basis.

Resources
The resources that you need varies from project to project. Since this website focuses on IT projects, then you will probably one or more developers or technically personalities, but resources can also be designers, architects, legal advise, security, machinery, buildings, servers and so forth.

It really depends on the project at hand, however there should be no doubt, when it comes to day to day business then the resources needs to know what they are supposed to build, not how to build it, in what order to build it and so forth. If you are a project owner, project manager, product owner or the scrum master, it is extremely important that you focuses on facilitating the project, support the resources and make sure that everybody is moving in the right direction.