Why Your Change Request Estimates May Be Out Of This World!
In my last post, I talked about why it is critical to have different roles involved in the Change Control process. Failure to include a larger team in change assessment is a common oversight that makes it harder to understand the total impact of a change request.
Staying with the Change Control theme, I see one other challenge that occurs across teams. It may not occur “every time”, but when it does, your estimate for a given change request may be off by orders of magnitude.
A typical approach to estimating change requests…
When developers receive change requests to estimate, they start by understanding
- the current functionality that exists,
- the desired change to this current functionality,
- the impact of the change and effort to complete the change.
While I know this is over-simplified and obvious, I want to drive into the 3rd bullet, assessing the impact of the change request. I believe most individuals assessing changes do a fairly complete job in assessing the impact. But there is a hidden monster (or pothole) that can destroy the accuracy of an estimate.
Let me illustrate with a quick (and over-simplified) example. I’ll call it …
The Grid
Let’s say your application includes a search screen that allows a user to search through all of the employees in your company. The search allows you to search for employees by office, region, tenure, etc.
A change request comes through that says they want to be able to hover the mouse over any employee record in the result and display the details in a pop-up bubble.
With a mock-up of the bubble and a clear understanding of the data, the request seems simple enough.
You estimate the impact of adding this functionality directly to this search might be one to two days to complete and have ready for business review.
Enter the hidden Reuse monster
As it happens, the employee search in this system is reused in several different areas. One of the areas is the ability for any employee or internal contractor to search for an employee’s name, office and phone extension. Because it isn’t obvious that this search is reused when first looking at the code, you may inadvertently add this functionality to all the areas where a user can search for employees!
But WAIT! Do you really want just anyone getting personal details of your employees? You probably only wanted the management group to have this access, right? So when you add this functionality, you now have either created defects in other areas or have to “break” the reuse and write this code separately.
For all my architect friends out there, yes there are better solutions to solving this problem. But here is my point:
Many times when estimating what implementing a change would take, we don’t verify that the code involved in the request is not reused elsewhere or that other dependencies exist.
We may do this when making the change, but we need to know this when estimating the change too!
It may impact our own estimate as well as the QA estimate for this change request.
So here’s the quick tip
When estimating for a change request, make sure you estimate the impact this change will have on functional or code reuse. It isn’t always obvious!
Can you think of any recent examples when your change request estimates were out of this world?
Category: Uncategorized
[…] process or simply don’t have one. I shared one commonly used approach in my previous blog post, WhyYourChangeRequestEstimatesMayBeOutOfThisWorld! To recap, a typical Change Control process usually […]
[…] to follow a defined process or simply don’t have one. I shared one commonly used approach in my previous blog post. To recap, a typical Change Control process usually goes like […]