#NoEstimates — The Leaner Approach
How reducing estimation effort along with a Kanban workflow can improve velocity and reduce waste
How reducing estimation effort along with a Kanban workflow can improve velocity and reduce waste
Key Takeaways
“Agile is dead, long live agility” (Dave Thomas)
#NoEstimates simply means reducing waste in tasks estimation
Experiment with different frameworks and create a process that promotes agility and reduction of waste
It All Starts With Agility
Nowadays, everyone knows about Agile. Or at least they work in some kind of process that is related to Agile (such as SCRUM). Truth be told, most of the people I talk to miss the main point of it.
To demonstrate it, follow the values and principles of Agile in the Agile Manifesto. How much of it was actually taken into today’s “Agile” (which is mostly SCRUM)? Moreover, Dave Thomas, who was part of the manifesto creation, went on to say “Agile is dead.”
It all starts with agility, the ability to move quickly (and I will add, in the right direction). I will describe briefly how Kanban workflow, combined with no estimates, can make your product team move insanely faster.
No Estimates?!
A quick Google search can bring up some results on where this movement had originated from, and probably a million different ways to implement it. I will just say the #NoEstimates hashtag originated in 2012 in a Twitter thread, and since it just keeps being in the headlines.
Moreover, the #NoEstimates approach can be anywhere from literally no measure of estimation to a more forgiving estimation with less stress. Either way, I believe it has something to do with challenging the status quo that SCRUM brought and suggesting a way to reduce waste.
In one of my roles as Product Manager, I had the flexibility and team collaboration that allows us to experiment and create our own way of #NoEstimates. Before I will go into describing it, the specific implementation I refer to has the following criteria –
There is no such thing as coming up with a measurable value to assess the issue complexity/time (such as story point or working days)
There is no shared effort of “estimating” a task
There are some agreements within the team on what a task should be (such as having up to 5 acceptance criteria or handle only one specific use case)
There are some processes that assist in proving timelines for features (such as velocity measured by the number of tasks over time)
How Kanban And #NoEstimates Fit Each Other
Continuing my example, my team and I have decided to try and reduce waste. To do that, we decided the following –
Move from SCRUM framework to Kanban
Move to a weekly team meeting
Not estimating complexity (story points up until then) nor time (like expected release date)
We should aim for all tasks be more or less of the same complexity
To clarify my meaning by Kanban, we built a minimal workflow with minimum meetings (mostly kept the Daily Stand-up) focusing on bottlenecks and efficiency. Moving to Kanban, with the goal to reduce stress, also reduced rituals and meetings thus the move to minimum estimation.
On top of that, It felt like we focus on clarifying tasks and working on them, instead of trying to guess how much time it would take. While SCRUM could work with other estimation methods, it felt flowing and low-waste to do it with Kanban. It is important to understand our goal was to improve the team development process, for example by reducing the time to review a PR
However, we live within an organization and schedules are important for syncing with other departments and reflecting progress. On the higher level, we knew to measure (by statistics) how much time on average it takes for the team to complete a task. With time, the team got confident in our process and we were able to provide sort of schedules without the effort of estimation.
Lessons Learned
Agility means moving quickly. I believe the #NoEstimates movement questioned some of the basics in Agile, which is SCRUM, and specifically estimations. As I mentioned, without predictability and alignment the product team won’t be able to succeed.
In my team experiment, I learned the following –
Teams can work in agility, and SCRUM isn’t necessarily the right framework for all teams
Teams can avoid, or at least reduce the effort invested in estimations without much impact on their process
Product Managers can create alignment and forecasting of releases without Sprints and Story Points
When focusing on the process, waste can be removed thus improving the team's speed
While I don’t advocate #NoEstimates, I definitely encourage experimenting and being creative in moving our teams from being Agile to building products with agility.