Hello again, it’s Steve Miller, VP of ALM Solutions for SmartBear. Last month I began blogging on a series of “Thorny Software Development issues” and this is a continuation of that blog. As I mentioned previously, I have been dealing with software development and testing issues for over 26 years, and I want to help you avoid some pain wherever and whenever possible.
When I work with project managers, they often ask “Why are my programmers always running behind on their deliverables?” This can be caused my many issues; I will talk about the common ones.
Estimates Must be Done By Programmers
First off, who is estimating the work, the project manager or programmer? If it is the project manager, that is your first issue. You should always allow the programmer to estimate their work because they are more intimate with the detailed things that have to get done for each programming task.
Requirements must be Decomposed
OK, so you say your programmers are estimating and they are still running behind. At this point, we need to dig a little deeper. Are the requirements properly defined and did the programmer take the time to put together a design when doing the estimate? If not, they are probably under-estimating because they did not decompose the requirement into low level design tasks needed to full-fill the requirement. The more you know about design, the better you can estimate. Let’s take an example. Let’s imagine that you ask your developer this user Story:
Create Customer Record
As a sales rep, allow adding a new customer to my CRM, saving the record by pressing Submit.
The programmer may be quick to answer based on their past experiences:
- User Interface Design - 4 hours
- Create Database Logic - 4 hours
- Create Business Logic – 2 hours
Total: 10 hours
Now let’s take the same scenario but provide better detail in the user story:
Create Customer Record
As a sales rep, allow adding a new customer to my CRM with these attributes: Company, Phone, Customer Name, Address 1/2/3, City, State, Zip, and Comments. Ensure that Company and Email are always required entry. Email should be unique and should contain an ampersand and a period to be valid. Upon add, capture in an audit, who added the contact and the date/time it was added.
Then ask your programmer to detail out this work so that she can come up with the best possible estimate:
- Create Customer Table -1 hour
- Create Audits Table -1 hour
- Create Stored Procedure for Customer Add – 2 hours
- User Interface Design for Stated Fields – 4 hours
- Create UI logic for calling Contact Add stored proc – 2 hours
- Create UI logic for calling Audit Add process – 2 hours
- Create Validation rules logic (required fields, etc.) – 3 hours
Total Estimate: 16 hours
As you can see, by decomposing the requirement into tasks, it will result in a better estimate. The refined estimate is 6 hours higher than the developer’s first ball park estimate and is probably much closer to what it will actually take to deliver this feature.
Watch out for Scope Creep
Another common issue is scope creep. You start off with a design, start coding and someone comes up with some cool enhancements to the feature you are working with and you try to fit that coolness into the same schedule. If that happens, you need to re-estimate the work based on the new features to ensure that it will still fit within your time constraints, and if it won’t, you will have to let the cool feature wait. You may also find during coding that a new requirement comes up because the requirements were not thought out enough. That is absolutely fine, just be sure to limit the scope in the current release or sprint to work you can accomplish and add the additional functionality in an upcoming release or sprint.
Buffering for People that Have Trouble Estimating Tasks
Finally, some people are not very good at estimating tasks. You have optimists that like to think they can get more work done than they really can (I fall into the category), and some pessimists that sand bag by putting these really huge estimates out there to cover their butts. Both of these issues are detrimental to a project, so you need a way of determining who estimates well and who doesn’t, and find ways to improve their estimating skills. Luckily, this is easy to solve. Have each team member estimate their tasks and track their time towards it. Then after the iteration ends, do a variance report (estimate minus actual). You will find that on the first go-around most of us will underestimate the tasks. Here is an example:
Then on your next iteration, collect estimates from each team member, but buffer them by the variance (based on the individual team member) from the last sprint. So if John was 25% under-estimated his aggregated tasks last iteration and he estimates 100 hours for his tasks in the upcoming iteration, make his estimates 125 hours.
Then in your retrospective, take the same approach (look at the variances in the new sprint and make buffer adjustments accordingly). Over time, you build a much better estimator and more reliable estimates.
You can easily improve your estimating techniques by having your programmers perform estimates, decomposing requirements into task line items, keeping an eye on scope creep, and by buffering estimates based on past history. If you want some additional tips and tricks for solving the poor estimates dilemma, watch this short video.
Miss part I? Read…and then watch the bonus material: Thorny Software Development Issues – Code Reuse
Stay tuned for the next thorny software development issue. In the meantime, why not share in the comments how you are estimating your tasks?