P50: A Sensible Way to Estimate in Software Development • heyfirst.co

Very well,

Short answer: No, I believe we can’t make an accurate estimation at all but we have a workaround for it and I will share my own experience here today.

This topic about estimation in software development has been discussed for decades, there is no right or wrong, only what make sense for you, your team and your company. And It is always tricky.

Also, It is very-very common problem, which is we often miss deadlines, which frustrates company, managers, and developers.

Well, Not so much here, at least the team and my unit I used to worked with, here we have a sensible way to estimate called “P50” that could help us overcome this problem

What is P50?

P50 or P50 date is a way of estimating that accepts that we can’t be 100% sure about how long something will take. It means there’s a 50% chance we’ll finish on time and a 50% chance we won’t.

The P50 date is our best guess for when we’ll be done, based on what we know now.

Why Use P50?

Using P50 date for estimate your feature work has some key benefits:

Realistic expectations: By admitting there’s a 50/50 chance of hitting the deadline, P50 keeps expectations realistic for everyone. All stakeholders need to accept this P50 date before we start and this will help reduce frustration when things take longer than planned.
Better planning: To come up with a P50 date, we have to plan carefully. We break tasks down, do research, and talk to everyone involved. Not only that, we take potential PTO or holiday plan, KTLO works, support works for other teams, and so on. This leads to better project planning and teamwork.
Flexibility: The P50 date isn’t a hard deadline. It’s a target based on what we know now. This gives us wiggle room to adapt if unexpected things come up during the project.
Clear communication: Using P50 helps stakeholders, managers and developers communicate clearly. This is really important, we don’t use the word “deadline”. Everyone has the same understanding of the estimated timeline and the fact that it might change. This openness and alignment is good for the team.

Examples of P50 usages

Here’s an example of how P50 can work in a software project:

Let’s say we need to build a new feature for a web app. The dev team does their homework - they make a technical plan, break the work down into chunks, and estimate each part.

They think about time for coding, meetings, sudden issues, and a bit of a buffer. With all that in mind, they come up with a P50 date of January 31, 2023.

They tell the managers, “This project P50 is Jan 31, 2023. We’ve got a 50% chance of being done by this date, and a 50% chance we won’t.” As they work on the project, the team stays flexible.

If new info comes up or they hit snags, they adjust the plan. They keep the managers in the loop about any changes to the P50 date and why.

Addressing Concerns

Some teams may be hesitant to adopt P50 date, especially if they’re familiar to more estimation methods like points. However, P50 can help address common concerns:

Stakeholder Expectations: By communicating the 50/50 nature of P50 dates, teams can manage stakeholder expectations and reduce pressure to meet arbitrary deadlines.
No guessing, No abstract: Using date directly helps everyone understand how complex the project is. With points as it is so abstract*,* team always need to convert from points to task, or points to man-day. P50 date is just a date where everyone benefit from it. Engineers know the roughly date they need to release feature, managers and stakeholders know roughly what a date things will be done. That’s it.
Budgeting: We found out P50 dates can be used to create more accurate project budgets (e.g. how much engineers we need and how long), taking into account the potential for delays or additional work.

Conclusion

For me, using P50 date is a sensible approach to estimating software projects. It accepts that we can’t predict everything, but helps us plan realistically.

By setting sensible expectations, planning well, staying flexible, and communicating clearly, P50 date can help teams ship great software with less stress.

No way of estimating is perfect, but P50 is a solid way to handle the twists and turns of software development. It gets stakeholders, managers and developers on the same page. By using P50 and always improving how they estimate, teams can get better at delivering quality software on time, with fewer surprises.

I encourage you to try implementing P50 in your own teams and share your experiences.

What estimation techniques have worked well for you? Do you have any questions or concerns about adopting P50? Let’s continue the conversation in the comments below. 🙂