Quite often in the lifetime of a product’s development something unexpected will happen that will throw your project plan out of the window and you will have to reorganise your resources respectively. This could be the customer changing their mind on some included functionality, adding additional requirements or the priority of requirements.
In this article I will continue the development journey with project planning using a time-boxing method to make sure everyone stays on schedule, interruptions are minimised and the customer gets what is most important to them. I actually wrote this back in April but didn’t publish as I thought it could do with some graphics to break up the text but apart from a burn-down chart I couldn’t think of anything else and in the end I decided to drop the burn-down chart and publish anyway.
Where do we start?
My previous articles; “introducing phases to an application development project” and “streamlining application development requirements“. As a recap we mentioned that we will be delivering our development project in phases and the number and duration of these phases (no more than four to six week each) would depend on the estimation of functional requirements. Those articles ended the development journey with the functional requirements written as user stories so the non-technical people could understand them. The user stories were divided into work tasks by the development team for more accurate estimation of the work involved. Armed with the user story estimations, these were verified and prioritised by the requestor.
We begin our journey with having to project plan the work and our resources but before we do that we need to make sure the estimations are correct. Easy to do if everyone was coding 100% for their time, the estimates were 100% accurate and the requestor (customer) never changes their mind.
Mind changing is partially covered by the fact that the requestor will be seeing something after 4-6 weeks at each stage of the development but we will cover that further later on.
Accurate estimations
So let’s consider the estimations from the developers. Some developers are very eager to impress and under estimate whilst others cover their backs by over estimating. You will have to know your developers and their personalities to tell which estimates need to be adjusted and how. You should be closely monitoring the project progress and will get to know how accurate a developer’s estimation is even when considering other work they may have. We can leave the developer’s estimates how they are or if you think they are unfair either to the developer or the requestor then challenge them. However, this estimation needs to be agreed before presenting to the requestor the total work estimations for the user stories for prioritisation.
Last but not least we have to consider other disruptions. From experience I know that my developers have to deal with support issues on other products, document what they are doing, record their time, maybe do some technology research, continue their personal/professional development with Research Fridays (Friday afternoon spent researching the latest technologies if they are not behind on their work) and many more so I only commit 80% of their time to coding and sometimes this needs to be less.
There are probably many names for the amount of time a developer will spend programming on a project but I have mostly called it coding capacity in the past so I’ll stick with that.
Project planning issues
So for project planning we need to know how much of the work will be completed in our 4-6 week phase and that depends on how many resources we will be using on the project. It seems quite simple to say we can cover 4 days’ worth of tasks in a 5 day period so 16 days in 4 weeks or 32 days in 4 weeks if we have 2 developers working on it.
However, things are never that simple. For a start adding a developer usually does not double the amount of work that can be completed because there will need to be collaboration and decision making time between the developer’s so it tends to work out at about two-thirds of the time saved but this only works whilst there are distinct elements that developers can work on, throw too many developers at the project and some will be waiting around. Next, during a projects lifetime, you will invariably encounter a requestor changing their mind either on the user story priority order of a new piece of functionality that never existed at the start. Of course you can extend the project time line but you have booked the quality assurance testers for a particular date and they time has been carefully organised to maximise their productivity so changing your timeline affects theirs and you might also have other products queuing for attention that you have a contractual commitment to.
There is another issue to add to the mix and that is the requestor will prioritise based on what is important to them and their customers and some higher priority user story might actually be dependent on something that the requestor deems a lower priority. All user story dependencies must be made clear to the requestor so if they think “K” is essential and that has a dependency on “P” then “P” must come before “K”. I usually use letters for the user stories which each also being assigned an order number once they have been prioritised by the customer and reordered by me (including dependencies).
Time-boxing
What you need to do is give a commitment to a period of time and stick to it. Your quality assurance testers and even your user acceptance testers will appreciate you delivering when you say you would and not only that, but sticking to the schedule means you priced the job correctly too.
Committing to a time period is what I call time-boxing. The time is the constant and you adjust what you have to do to fit in with that time. Hopefully, your estimation and the coding capacity, priorities and phases have all been established before you commit to a time-box.
Working in a time-box means that a customer changing their mind by adding extra requirements has two choices, paying extra for the additional resources that you will need to add to the project or they will have to drop one of their other user stories from this phase until a later phase of the product development lifecycle. In the case of internal development teams working on internal products for internal requestors the addition of extra resources is not usually feasible so the functional requirements for the phase are the only thing you can adjust.
Finally, an example
You will have to present a project plan of how you think it will all work to the requestor/customer. Here’s an example of the project phases time-boxed with 40 prioritised user stories.
- May 18 to June 19 (5 weeks of 2 developers)
Contains the structural elements together with User Stories ordered 1 to 9 (this might be A, B, P, K, F, G, H, I and C as an example). This is for internal testing and demonstration and not a public release. - July 6 to July 31 (4 weeks of 2 developers)
Contains everything that is essential building on Phase 1 with User Stories ordered 10 to 17. This is a first public release as soon as it has UAT sign off. - September 14 to October 16 (5 weeks of 2 developers)
Contains all the nice to have bits building on Phase 2 with User Stories ordered 18 to 28. This is a second public release as soon as it has UAT sign off.
So, in this case, you would be initially charging the customer for 28 development weeks of work spread over a period from May 18 to October 16. However, as the User Stories for Phase 3 are those not deemed essential they could be replaced but the customer for something more pressing after feedback on the first release. If those replaced User Stories are still required then we can have a Phase 4 scheduled for later in the year at the customer’s expense.
I think you’ll agree that working this way makes sense to everyone involved in the project. The customer as they are getting what they paid for on schedule. The Company will be paid the agreed amount for the agreed amount of scheduled work. The developer is working to their own estimate and a scheduled timeframe and the testers that can plan to be available at the right time and know that you will deliver at that time and the project manager can schedule other projects between these phases.