It has been some time but this article follows on from my previous article about breaking an application development project into several phases; introducing phases to an application development project. In this article I will cover how to break the phase or whole project (if it is small enough not to require breaking down into phases), estimating the amount of work and prioritising the order of that work.
First up, the project or phase needs to be broken up into tasks that can be described by no more than three sentences. Usually, if it takes more than that to describe the functionality then these tasks need to be broken down further. You will need to divide the project or phase requirements into “user stories” that describe the intention of the functionality. When you have all of your “user stories” each of these can then be broken down by an experienced developer into actual tasks or steps that they will need to perform. This enables more accurate estimation of the length of time it will take to perform those actions but we’ll get on to that in a minute.
Use Cases versus User Stories
You may have noticed that in the previous paragraph I have been referring to “user stories” rather than the more traditional “use cases”. This is because “user stories” are my preferred method for describing the required functionality and I will explain why.
A “use case” describes an issue or challenge from a technical perspective. It is very formal and worded so that technical people such as the analyst, programmer, code reviewer or quality assurance tester all know exactly what is being requested from their perspective. It is very hard for someone outside of this field of expertise to completely follow. Typically “use cases” would be the instruction to the technical team after a separate requirements document was agreed with the requestor. Asking a requestor to review “use cases” is a waste of time. Part of a “use case” will list the functional steps to overcome the issue or challenge which is very useful to the quality assurance tester as they have most of their test plan already written.
So in this scenario we have a requirements document that the requestor agrees, a technical specification with “use cases” that the technical team all agree but the requestor does not and a test plan that is derived from the “use cases”. Quality Assurance is followed up by User Acceptance Testing (UAT) and it is only at this point do we see if the technical team made the right calls when deciphering the requirements document.
A “user story” describes some functionality from the requestor’s perspective. The requirements document would be used to describe the issue or challenge and present a breakdown of the solution in a jargon free manner.
As the requestor understands the “user stories” they are in a better position to tell you if your understanding is correct. I think there is less scope for things to go wrong, especially when you get to do the estimation of the “user stories” as you will be clarifying with the requestor the required functionality so that no assumptions are made
Assumptions and Estimations
When you have written up all of your “user stories” and broken them all down so that each description serves a singular purpose then it is time to work out an estimate. This is not something you will do on your own (unless you are an analyst programmer). A developer will need to break each “user story” down into technical functionality and make an estimate of how much time will be required to build these parts. However, they may not have all of the answers to be able to accurately determine what is required based on your initial “user stories”. You will need to check everything back with the requestor unless you are absolutely sure of the answer.
There can be no assumptions! Assumptions invalidate estimates and you can end up building functionality that is not required or missing something that is. Always check and when you have no assumptions left, you can be sure that you are building what has been requested and can get better accuracy in the estimation. If you ever see a list ending with “etc…” that is not predefined elsewhere then it should raise a red flag and needs to be clarified with the requestor.
If available, ask more than one developer to break it down into technical functionality and estimate (then you can validate the technical aspects and take an average of estimated development time).
User Story Prioritisation
The final check back with the requestor before you ask them to sign off on the “user stories” in the requirements document is for prioritisation.
Every “user story” must be weighed against all others in order of importance to the requestor. It doesn’t matter what rating system you use; Low, Medium, High; range from 1 to 5; etc… but this needs to be mentioned in the requirements document and preferably be consistent with what has been done in the past especially if working with the same requestor.
This is the last job you are going to give to the requestor until they are required to provide User Acceptance Testing. UAT may not be performed by the requestor themselves but it is up to the requestor to arrange a test and sign off on their side and not just rely on the technical teams quality assurance testing.
What happens next?
As mentioned in my previous article in this short series about phasing the development project, the project or phase should take a month and not take longer than 6 weeks. When you add up all of your user story estimates you will see if they meet this criteria. If not, you can either add more developers to the phase or move some of the lower priority items to the next phase.
That’s it for streamlining “user stories”, estimations and prioritisation. In my next article I will cover project planning using the time boxing method to keep everything on track.