Both standups and estimation have value, depending on your team. If you
have a dedicated project manager who scopes the next sprint's work, they might benefit from
points-based estimations because they can measure how much progress to expect
next. And if you work on a team building a high-touch customer-oriented product, you might benefit from
a daily standup to keep your non-technical stakeholders in the loop.

But I've been on too many teams who did one or both of these rituals even
though they didn't provide any tangible value. And in many cases, the maturity of modern
network tools has rendered these rituals all but obsolete.

Are your daily standups redundant?

Before the likes of GitHub pull requests, it was difficult to, at a glance, see
what your teammates were spending their time on. If they had a question, the
daily standup served as a space for making inquiries without feeling like you
were interrupting their day.

But now that GitHub pull requests enable a one-click view of ongoing efforts by
your team and a vehicle through which questions can be asked and answered on
our own time, the daily standup is a relic of a less connected past.

And even if you do commit to a daily standup, does it necessarily need to be a
synchronous meeting where everyone is present at the same time? I've worked on a
team with a #standup Slack channel. We each post our daily standup in the
room. Everyone can read up on what the rest of the team is doing that day and
whether they're blocked. And no one has to interrupt their workflow to do it.

Ask yourself: Do you get much or any value from your standup, or
is it just another mindless ritual?

Are your estimations meaningless?

Stakeholders want to know how much their software is going to cost. This is
a reality with which every software developer must contend. But another reality
is that software estimation is a losing
game.

We can try, to the best of our ability, to assess a software problem and
estimate how long it will take to come up with a solution. Armed with an
understanding of a fixed software problem, estimating the time to build
a solution is actually relatively easy. But software problems are rarely
understood correctly ahead of time, and are rarely ever fixed.

Most software problems are complex enough that they require further inquiry
after beginning development. There might be a variable we didn't consider
during estimation. We might have misunderstood the original problem and gotten
that feedback from the customer halfway into development. When was the last
time you developed a piece of software without asking for clarification from
your customer in the midst of development?

And even if you're fortunate enough to understand a problem thoroughly enough
to implement it to the customer's desires the first time, there's a good chance
they'll change their mind about it in the middle of development. Maybe they
think of a better way. Or maybe business conditions have changed and it makes
more sense to do things differently. Whatever the reason, requirements change.
And when requirements change, you can kiss your original estimate's accuracy
goodbye.

Okay, then what do we do instead?

Estimation and daily standups attempt to solve a real problem: Making sure
everyone involved in your project is held accountable and are aware of the
changing conditions of your project.

If your team reports that they find value in these activities, then keep doing
them.

But if you really consider the opportunity cost of continuing to live by these
rituals, you might find their cost outweighs their benefit.

Does interrupting everyone's flow during ongoing high-value development work to
hold a daily standup have a net benefit to your team's productivity and
happiness? Or would the team be better informed by committing to reviewing open
pull requests and tickets once per day on their own time?

Are your estimations providing your product owner with valuable insight into
what progress they should expect in the coming months, or are your estimates so
skewed from reality that they're meaningless?