Describing projects

Status: readable.

Some suggestions on ways to gather and organise information from clients about projects.

Each of these suggestions should work independently from each other, so feel free to pick and change what works for different projects.

Question feature requests

This does not mean becoming defensive about changes, it simply means trying to understand why a client wants something done.

Clients may request features because they are unaware of alternatives.

Requests may also be based on existing work-flows that will change with the new product, making the feature unnecessary.

Discovering why a client wants a feature will help decide if and how it should be implemented.

Define user types

Before deciding on features, it is helpful to know the types of users that want them.

Here are some of the possible user types and their main goals for a messaging application:

You can even give names to the user types to make it easier to refer to them, like Gary the group manager, Anna the account manager and Sam the system admin.

Use stories to describe features

Features of an application can be described as stories:

As a group manager, I want to add a user to my group, so that they can receive group messages.

The usual structure is "As a ? I want ? so that ?". This specifies the type of user, the feature they want and the reason for it.

The "so that" part is used to justify why a person wants a feature. This may expose issues with the feature that lead to a better solution.

Decide importance of features

Features should be given an importance in relation to the project.

Define test criteria for features

Every feature requires test criteria to describe when it is complete.

Using the previous story, the test may be:

Given I am a group manager and I am on a user profile page, when I click the "add user to group" button, then the user becomes part of my group.

The main structure of the test is "given ? when ? then ?". Each of those sections can include multiple states, actions and results that are joined with "and ?".

These can be used for automated testing with Cucumber for Ruby, Node or Python (as Lettuce).

Rate the complexity of tasks

These scores are relative to each other but do not convert to specific times.

This is a guide for how I usually rate tasks. These vary between projects so they should only be used as a starting point.

You can then add the scores of tasks done over a certain time frame to figure out the rate at which tasks can be done.

An alternative to numbers can be to use clothing sizes, like S, M, L and XL. But this will not allow calculating the task completion rate.

Regular feedback

You should try to have something to test at regular intervals, such as every 2 weeks.

Feedback from client testing may result in scope changes. This is not a bad thing, as long as the client is made aware of the consequences of the choices they are requesting.