OK, so this is a topic that comes from a conversation I had last week with a PT customer who is also a listener of the Podcast – Yes, I found one! And, this ones’ for you!
Now, To make a long story short, we talked about cases when you are asked to provide estimations on “How long it will take to test” something, without getting much more than the title of a feature or an Epic. Sounds made-up? Believe it, it is not! It has happened to me in the past as well.
Even if this is an extreme case, there are many instances in which we are asked to provide estimations of test time, without having much to base them upon.
What do you do in these cases? How can you provide numbers? Is there anything else you can do to ensure that you are not going to be blamed, when you are not able to make these numbers later on in the project?
Sounds like a simple problem – JUST SAY NO When someone asks you these kinds of questions.
But in reality, you can’t say No. So what to do, in a professional way, to cope with these challenges.
This is what we want to talk about today.
Let’s talk about this specific story. It is a bit of an extreme, but I think there are a number of things we can learn from it
- So this test manager was tasked with providing estimates, but the catch is that she only had the name of the features to provide these estimates. No functional descriptions, no infrastructure requirements, no low level or even high-level design, nothing.
- The only thing she did have was previous experience, since she has been working on the same organization with the same development teams for the last couple of years… And this is what she used in this case.
- After reviewing all the options together, we agreed that the best approach would be to provide estimates on the required testing time based on previous projects they had done that “sounded similar” in content and complexity.
- The caveat to this approach, and this is also what makes it less of a throw of the dice, is the fact that when she provides the estimates she will:
- Explain how SHE understands the high-level definition of the feature, what technical and infrastructure assumptions she is making, and what risks she foresees on these assumptions
- She also will base her estimates on 2 or 3 different previous projects, and explain how she reached a number that is basically an average, so it is more of a range than an absolute figure.
- All this may sound trivial, but it is not. We had to talk for a while in order to come up with this idea. And we were only convinced about it when we understood that she would be able to share the risks of these estimations with the rest of her management team, as she was sharing with them all the assumptions she had used.
Even if you provide a number when you give your estimates, make sure to explain how you came up with these figures
- It should not be inspired on numbers you see in the clouds, or by reading the trace of your coffee in the morning
- Take the time to understand and calculate
- Prior “does take” time can be helpful – this means understanding how long something took in the past and using it to guide your estimate.
Share your assumptions
- If you are assuming something, make sure you bring this up and that it is clear.
- For example, if you are assuming that the feature will be stable and you will not find more than, let’s say 50 to 60 critical bugs in the first month of testing, then make sure this is known.
- If you expect to have people in your team that answer to specific levels of experience, make sure this is known
- If you will need to receive the software based on a specific schedule, this needs to be known as part of your estimations.
Work in ranges
- It is close to impossible to hit the nail in the head when providing estimates. You will either miss the number (most times this is the case) or overshoot it (and if this happens, next time people will think you were exaggerating).
- Provide ranges, for example 10 man-months / plus-minus 2 man-months
Revise your estimations on a regular basis
- Remember those assumptions. They will definitely not be correct!
- Set up intervals and revise your assumptions to make sure you can communicate any changes
- The same goes by your dependencies, make sure you are on top of them, and as the project progresses and changes are made, update your timelines and estimates live.
Make sure people understand that you are most likely to be wrong, and you are providing an assumption that will help the team move forward and plan further.