No estimates; hype or not?

#NoEstimates seemes to be the next big thing in software development

Is it because

estimates are lies and estimation waste ?

-hey: wait a minute! I have seen value in the estimation process. This post shows the difference.





The first thing to figure out is: Why do we estimate in our team? Is it due to lack of trust, and the urge to micro manage and illusion of control, not focusing on value? in that case, maybe solving the underlying issues should be the number one priority :) just tossing away estimation will not solve any of these more severe issues.


On the other side; estimations might be for the internal use in the team. An estimate is a solid number, it is something that all team members can relate to, and figure out if the team has roughly the same understanding of

• the problem
• and solution,
• what is out of scope,
• what is needed,
• what is nice to have,
• what is over-engineering,
• what are the risks involved,
• what dependencies do we have,
• what test coverage and state is in this part of the code,
• how familiar are the team members with the code, domain and goal.

In other words: Estimation can be used as a means for communication within the team.

And: Only a limited number of software development challenges has a fixed scope. To discuss in the team what is the smart thing to do is a positive effect of valuable estimation.

 

The impartant question is this: Does estimation give you true value? If not, see if you have more severe underlying issues to deal with and get rid of your estimation process.

How to master the power of «No»

It is easier to say yes than to say no. But remember:

Saying "No" is not having a bad attitude. Saying "No" is making a choice.  

Every good software project has some people that are great at making choices

This is how to do it:

 

I often find myself talking with business people. And usually they want everything in the whole world (at once): they want all the functionality you can think of, there should of course be no bugs or downtime in the system, and they want it all as soon as possible! This is especially true at the start of any project, or early in the release cycle.

Delivering software boils down to the ability to say no to some really appealing features. These features will not make it into the next release –a harsh truth. And we leave this out in order to secure and deliver what is even more important.

 Sounds simple, but it is hard in real life!

Why is it hard to say no?

• You feel better if you say yes –in the short term. In the long term you will need to handle to much, and you will see some of your things slip
• You make the requester happy –in the short term

What is the art of saying no?

Ignore the instinct to get the rush of reward when you say yes. Think of the implications:

• Reprioritization is always possible :) It is all about doing the right stuff first, and not fall into the trap of scope creep
• What stuff will need to slip?
• What will be the implications for the customers, the organization, the employees, the short term and the longer term?
• What is most important?
• Do not bluntly say “no”. Start with your purpose (your shared goal), what options you have and implications.
• Ask back: what is more important?
• And a really helpful question: is this a showstopper?

After this exercise, you are back on the same page on what is most important and how to move on. You are helping each other to focus on the right stuff and you have the right amount of work to keep the flow. This is a great place to be!

"No" means "Yes" to something else!

·         No to random interruptions scope creep

·         Yes to the right focus

·         Yes to flow

·         Yes to shorter releases

·         Yes to fewer bugs

·         Yes to reprioritization

·         Yes to take something else out

photo attribution