No Estimates: A Brief Introduction and Practical Uses

Estimation has become engrained into our daily lives. How long will it take me to get to work? What should I budget for my grocery spend this month? Literally on a daily basis, we surmise outcomes virtually from thin air. This behavior has infiltrated the workplace and now has become a cornerstone of project planning without which we feel we could never dream to begin our work.

As it relates to project management and software development, clients predictably lead with a few standard inquiries: How long will this take? And how much is this going to cost me? If you’re not familiar with the No Estimates movement, you may feel like, yeah, these are reasonable questions that I should be able to answer with some degree of accuracy.

While we can understand, as humans programmed to think we need estimations to make wise decisions, that a customer would want to know these projections from the get go, humoring this need, in fact, works to the detriment of how we go about managing our projects.

In the 1950’s, the Japanese began a movement focused on Lean principles. They found that keeping an inventory or parts and pieces needed for manufacturing was a poorly designed plan. It can be difficult to grasp at first, but they soon realized that having their materials supplied “just in time” was a more efficient and cost-effective use of their resources. It allowed them to utilize warehouse space for revenue generating activities rather than a store, and it enabled them to cutout unnecessary upfront costs.

No Estimates is another type of Lean system. Deciding which activities are slowing you down or wasting time and money on the front or back end as they relate to estimating practices and eliminating the need for them altogether are at the core of this method.

Why we’ve become addicted to estimating

We’ve quite literally become addicted to the practice of estimating. It provides certain levels of comfort to feel as though you know what to expect. The problem is that estimations are little more than guesses providing us with a false sense of certainty. Having financial projections allows for budgeting but in the case of companies working on software development projects, the return should be the focus, not the investment.

Why estimates don’t work

Estimates simply don’t provide the benefits we’re programmed to believe they do. There are far too many uncontrollable variables in the workplace that prevent 100% smooth project progression. Software development projects require multiple teams with varied skills and skill levels. Not to mention, rarely are we ever working on simply one project at a time. This being said, the act of transitioning a project to the next team is hardly ever a perfect baton hand off.

People take vacations. They take leave for personal reasons, and they take ill. These factors simply cannot be foreseen and can completely blow your estimations out of the water. Not only can setbacks like this push back estimated deadlines but there’s a chance you’d need to bring in outside sources to finish the job hence creating unforeseen uplifts in your estimated budget. So much for estimations.

Estimating comes with other dangers such as living up to those estimations. This can go either way, but keep in mind that once goals are set people adjust their workflow expectations to meet that exact goal. If expectations are set high, you could end up with stellar project outcomes, but you run the risk of falling short. Set estimated goals too low and you’ve sold yourself short.

Don’t forget the most unpredictable factor of all: the human factor. Our estimating abilities are undeniably tied to our personal emotions. For instance, if given a project and told that if you muck up and fail to meet your projections you could risk losing your job, chances are you’ll err on the side of caution and provide conservative estimates. Again, you could be selling the project short instead of saving your job. On the other hand, someone in a sales position could very likely inflate their estimations to give themselves more room to make a buck.

All things considered, we’re coming to see how estimations, while we think we need them, are little more than comforting and restrictions.

How to work with clients without giving estimations

To be clear, No Estimates dictates that we eliminate as much estimation as possible. There are circumstances where estimating will be necessary, but relying on estimations too much is a waste of time and energy and directly conflicts with Lean business practices. This is where forecasting comes into play.

Forecasting and Estimating sound similar. The main difference is that forecasting involves the use of known factors to surmise an outcome. Much different than estimating which is providing simply the best guess. Forecasting can be useful in working with clients that require some upfront “estimations,” but be mindful that past performance doesn’t perfectly predict future outcomes. As we’ve said before, unforeseen factors arise with employees and teams in the project stream.

Managing stories in slices

Your client has provided you some stories at the onset of the project. Tackling each story in its entirety at once may seem like the correct route, but really, it’s not. Breaking down stories into manageable and actionable slices provides you a way to report progress on a more frequent basis. The more frequently progress reports are needed, the more slices you’ll need to make into each story. Discovering which stories are necessary for your project is also important on leaning out your process and reliance on estimations.

An example could be made from a standard IT ticket submission by an employee:

“I need to be able to submit issues to IT so that a particular problem can be fixed which prevents me from working.”

Simple enough, and possibly too small to slice up, right? Wrong. Breaking this request or story down into several slices helps determine the amount of work required to fix it. Picking apart this particular story, we can decode the request into two actionable items:

  • Employee needs to be able to contact IT
  • IT needs visibility into a queue of issues waiting to be worked on

We’ve successfully limited the scope of our solution by identifying two features to focus on that will inevitably solve the issue. Slicing stories into multiple actionable parts helps us to actively manage projects.

Slicing up stories also helps with time management, a piece which helps to eliminate estimations. Breaking up stories into chunks helps to separate quick tasks to those which more time-intensive. This particular form of “chunking” enables your team to implement temporary solutions in a live environment, therefore, mitigating risk. It may be a few more steps, but overall it helps with operational implementation.

Some stories need to remain intact. Such stories should be given a maximum calendar duration a couple of months, of course, depending on the overall size of the project. Anything broken out of these should be given a maximum duration of a day. Any user-specific story should not be granted any level of advanced priority beyond a one-week timeframe.

Breaking stories out based on this practice enables you to determine how many of each category can be completed in a given time frame and provides accurate forecasting capabilities.

Track historical data from the start

Providing progress updates is essential in keeping clients who have not embraced the No Estimates theory happy and secure in your ability to complete the project according to their expectations. If data is not collected from the onset of a project, it can be difficult to piece together a before scenario due to changes in technology or staff.

For example, keeping track of your story deliverables (in slices, remember!?) can allow you to extrapolate how many RTSs you’ll be able to produce over the life of the project. This type of forecasting (not estimating) can be valuable to your relationship with the customer and goes far in demonstrating project progression.

Making the transition to No Estimates

Changing our way of thinking and the manner in which we do things is difficult no matter the task. So, we should expect nothing less from the implementation of a new project management process. Baring this in mind, cutting out estimates on day one of the transition is not realistic nor is it expected. There are, however, several things you can do to pave the way to a lean, No Estimates, project management practice.

Create story points

Basing your projections on story points rather than days and monetary costs is the first step in the No Estimates change. The benefits of story points are important and much more helpful than providing nothing more than a generic timeline. Story points help you to discover dependencies and complexity of issues. Story based estimation allows you to break a project up into predictable milestones.

Eliminate estimating task timelines

Trying to gather data points on story progression is counterproductive especially when compared to the overall time estimate to completion. Often we’ll see a story broken down into sub-stories with estimated timelines only to find that when they’re added back together, they don’t meet with initial expectations. Anecdotal progress updates are more useful to your overall completion goals.

Limit time to complete stories

Any story that starts at the beginning of one iteration that isn’t completed by the end of it points out a failing in your organizational structure. By limiting the time stories are allowed to be floating out there without resolution helps to point out these shortfalls and further your No Estimates program development.


As mentioned before, keep track of the time it takes to complete different types of stories. This type of information can become invaluable for future project forecasting.

Realizing when you’re late and what to do

Just because we’re aiming to rid ourselves of estimated time restrictions doesn’t mean that we’ve exempted ourselves from being off schedule or coming in late. One of the primary reasons for delivering a project behind schedule is because the scope was unrealistic, and the only way to remedy the situation is to have a serious talk with your client about reducing the scope of the project.

No one ever wants to admit that they’re not able to finish exactly what they’d set out to do, but it’s important to understand that if you followed the No Estimates theory and worked on the most important elements of the project first, it is likely that the client would be able to do away with certain items in order to get the project wrapped up. Maintaining flexibility and organizing the project so that it’s simple to see that each component or story may not necessarily be reliant on the next helps one to recognize that it is possible to deliver on some but not all of the original story requests.

It is quite common for the scope of a project to grow while it is still ongoing. If you’re worried about the scope being inflexible, the mere fact that additions can be made on the fly will tell you that it surely is not. Adjusting down as you go is a stellar way to keep a handle on the overall scope of the project. As you begin to understand the stories provided and begin to weave the solution, you’ll find that some of the stories don’t need resolution after all.

In the end…

We’re addicted to estimating. Estimating is difficult to get away from and hard to make people understand why it’s not only useless but also detrimental to our success in accurately setting expectations and creating optimal workflow efficiencies. So, what do you do? Changing the way an organization thinks is a mountain to climb and realistically can be impossible. That’s the truth. But, there’s nothing stopping you from implementing No Estimates practices within your team. Demonstrating the benefits of change is much easier than asking someone to quit cold turkey. Incrementally implement the No Estimates methods into your project management style and see for yourself just how superior they are to traditional estimation systems.

If you are interested in learning more about #NoEstimates you can buy the book NoEstimates, just click here.

Living Eulogy – Agile Retrospectives

by Jessica Long

Agile Retrospective Activity

The most unfortunate thing about a traditional eulogy is that the subject of gratitude isn’t around to hear it. An agile sprint is a lot like life overall in the sense that it’s over before you know it. Don’t wait for a moment to become a memory. Capture it. The Living Eulogy Retrospective is one of the more uplifting and unforgettable exercises that I have had the pleasure of driving. If there were ever a way to humanize a team’s DNA and build upon a bond, this is a surefire way to do it.

What you can expect to get out of this exercise

Focus will be diverted away from the traditional accounting side and reflection of the iteration. Concentrating on the people instead of the process humanizes an otherwise methodical system oriented examination. This will result in improved team harmony and synchronization. The exercise is beneficial for both maturing teams and groups that may be struggling with internal team level conflict.

How to do it

Hand each teammate a sheet of a paper as you introduce the exercise. Instruct each person to put pen to paper and identify who they are and what team they represent on the top of the page. For example, “Jess Long is a teammate for the Ginger Snaps.” Explain that upon your mark, each person should hand their paper to the left. The receiver will have 2 minutes to write an expression of gratitude or describe a positive team contribution that praises the subject at an individual level. This can be a single sentence or a short paragraph. Upon hearing the buzzer at the 2 minute interval, the teammate should hand the paper to the person on their left. This action will repeat itself until the papers make their way back to their original subject.

When you receive the sheet belonging to the person to your right, this will indicate that you’ve reached the final round. Urge the final writers to hand the papers back to their owners face down upon hearing the buzzer. Once everyone has received their original sheet, it’s time to ask for a volunteer to read his or her living eulogy to the group. Most participants are eager to see the mysterious sheet that lies before them but if there’s hesitation, you can opt to go first. This is the fun part. As the paper is flipped and the summaries are read out loud, there can be a lot of laughter around subpar penmanship and sometimes even tears of endearment.

Once everyone has had a chance to read, thank the group for extending themselves in such a personal manner. Reflect on the experience and express that you hope each person values their living eulogy as much as you value your own. Urge your teammates to hang these up or keep them in a place they can easily access. Chances are, that is already the intent of your team before you even suggest it.

About Jess

Jess Long has driven multiple Agile Transformations within several large financial institutions. Her love of coaching has enabled her to be a servant leader to many teams and provide individual direction to each of the specific roles that make up a successful Agile alliance. While she values each ceremony that goes along with an iteration, she embraces the sprint retrospective most of all.

If you have questions related to this article, please feel free to contact Jess on Twitter @ScrumAndGinger or through

Picture credits go to: Improve It.


In case you are interested in Agile Retrospectives OIKOSOFY has prepared 10 Days FREE AGILE RETROSPECTIVES PROGRAM for you. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us on the format of Guest Blogging please contact us:

12 important lessons learned by experienced Scrum Masters

scrum masterSince the beginning of the year 2015 we´ve been running one of the most popular scrum podcast in the world “Scrum Master Toolbox Podcast”. Hundreds of Scrum Masters around the world share with us their own experiences, learnings as well as failures throughout their career journey.

Credits to the lessons learned in this article belong to: Jeff Kosciejew, Dominic Krimmer, Stefano Porro, Andy Deighton, Matt Dominici, Tim BourguignonLuis Goncalves, Steve Holyer, Neil Killick & Antti Tevanlinna.

1. Define your way to measure success, and follow your own development

To achieve success as a Scrum Master you must first define success and measure your way there. There are 3 questions you can ask yourself in order to assess your success:

  1. Did the team deliver production-ready software this sprint?
  2. Was everyone happy with and proud of what they achieved?
  3. Did we improve our way of working (e.g. did we deliver more value than in the previous sprint?)

Having a checklist to assess your performance as a Scrum Master is another good option to measure whether you´re on the right track:

  1. Do we have a Team Vision?
  2. Do we have a clearly defined Sprint goal or focus?
  3. Do we keep our Scrum board up to date to make our work visible and transparent?
  4. Do we have a dashboard to communicate to others the status of our product?
  5. Do we have good quality stories?

It´s important that you sent your own list of questions or your own checklist, which you can regularly follow. This list will help you to focus on the right topics so that you develop your skills as a Scrum Master.

2. Be away for a few days and assess how the team took ownership of the process and meetings.

The most common definition of success is that the Team “owns” the process. This could be in different forms: teams owning the meetings or actively interacting with other teams or stakeholders in the organization. However, the tough question for Scrum Masters is: how do we help teams to “own” the process?

The level of ownership can only be seen when you are away. When you are away for few days, you come back and find the team lost and the process abandoned, that’s a clear sign that the team is not yet ready to “own” the process.

3. Focus on defining and providing a platform for your team.

You as a Scrum Master you should provide teams the right conditions and the environment that enables others to succeed. A very important characteristic for Scrum Masters is being in the background, this is supporting and enabling role.

Each practice requires a different approach to creating the platform. When teams have daily standup meeting, you can stay in the background, not interfere with anyone. Only step in when the team needs your support, in such situation you should facilitate the meeting. Stepping back allowing team to handle meeting themselves is a great step for them to realize that you´re there to support them and encourage them to take the ownership of the meeting.

4. Have many 1-on-1 conversations and take notes
scrum masterSo simple, yet powerful. The conversation is the most often used tool by the Scrum Masters we interviewed. Conversations are a simple tool, but often forgotten. One way to improve your conversation skills is to read How to win friends and influence people, by Dale Carnegie. The author talks about a list of things you must have in mind when you want to grow a relationship with people you work every day. You should always start talking about something other person cares about, don´t judge or argue, be interested in what their opinions are.

5. Help the team define their purpose, so that the team finds their own definition of success

Having a clear purpose is one of the keys to motivation and to success. Without having a shared purpose the team is not able to align their actions. A good idea is to do a workshop to define a team´s purpose. As an inspiration, take a look at the book Drive: The Surprising Truth About What Motivates Us written by Daniel Pink. We run this workshop very often, so if you´re interested in having us to facilitate that workshop, do not hesitate to contact us at

6. Learning to coach the team is one of the most important journeys for Scrum Masters

Scrum Masters do not get successful unless the team succeeds too. For that Scrum Masters must learn to work with the team. That means they must enable the team and their work, not do the work for them or solve their problems for them.  The coaching stance is a key aspect of the Scrum Master’s work. In a bonus episode, Bob Marshall describes Nonviolent Communication (NVC). It´s an approach that can help the Scrum Master with concrete tools, which will help the interaction with teams. NVC means we can’t force anyone to do anything, rather we must ensure that the reasons to do something are clear and and accepted.

7. The team you worked with yesterday is not the same you will work with tomorrow

Every team is constantly evolving, literally every day. The way we work with teams must also evolve to adapt to the stages of development of that team. Speaking of team development stages, according to Tuckman there are 4 different stages: Forming, Storming, Norming, Performing. Understanding what stage the team is in and what is the right approach for that stage is a key skill for Scrum Masters.

8. Coaching happens between consenting adults; get consent before you get started

We cannot force a team to be coaches, it required the consent of all who are involved. You should design your own coaching alliance with the team before you even start work as a Scrum Master with a specific team. This is a shared goal and set of expectations that will later enable you to ask the teams if they are committed to the initial agreement and remind them on what they agreed. This coaching alliance is your “contract” with the team and help you to redirect the team on the overall goal.

9. Measure all the things, and keep notes about 7343762168_d58fe252e2_oeverything

By measuring and keeping all metrics we are able to track trends over time. Here´s what you should do on daily basis:

  1.  Keep notes on everything. In meetings, after conversations, all the time.
  2. Measure everything you can: tasks completed, cycle time, features, interactions, etc.
  3. Get numbers on everything you do as a Scrum Master. How many times did you talk to each team member this week? How many times did you feel lost, or did not know how to go forward?
  4. Look at trends. Only numbers can help you see trends. So measure and stand back to see the big picture.

You don´t have start with every possible metrics. Start from small and define 2-3 metrics you would like to keep track of. Use the next retrospective as the trigger to your measurements. Choose a topic you would like to discuss in your retrospective (or ask a team to do that). Keep metrics related to that particular topic.

10. Measure team happiness to assess sustainability

There are few tools that you can use to measure team happiness. Journey Lines is a tool that you can use in the retrospective to evaluate a sprint from the individual or the team’s perspective. Happiness Door is a tool that combines a few other tools with the goal of measuring happiness on a regular basis.  This is a more real-time tool, designed to help the team reflect and react to what is going on at specific points in time. There are few other tools and methods to measure happiness, the idea is that you can measure happiness as a symptom of sustainability and design the methods to specific topics that affect the team.

11. Success is about producing something of value, help the team measure the value produced

It is actually possible to produce high quality software without producing any value. It is the success of your product in the market that defines your success at software development! Important lesson learned! As Scrum Masters we must be able to help the team understand if what they are producing is valuable. We can do this by having the Product Owner interact with the team, and the customer to define and validate the value of the software we produce. It´s not always possible to ask a customer about the value of the produced software, therefore Scrum Master must work closely with the team and the Product Owner to define ways to measure the value of the software delivered by the team. Take a look at the Lean Startup community where some methods are being discussed.

12. The feedback cycles are the most important tool for Scrum Masters

Scrum Masters must understand what type of feedback the team needs to get their job done. The review meeting is where basic feedback cycle starts. The team demonstrates the functionality they have accomplished and collect feedback from all stakeholders. The Scrum Master has to ensure that this feedback cycle is quick and effective (1-2 weeks). Proper ways to collect and process feedback is necessary so that the feedback is received with positive open mind.

When the team finally “owns” the process, people think that the work of Scrum Master is over, but it never really is. Once the team “owns” the process, we need to focus on these areas: the team dynamics, organizational impediments, interaction with stakeholders, etc.

After interviewing many Scrum Masters, we see two major definitions of success for a Scrum Master:

1. helping the team to succeed as a team

2. helping the organization succeed as a business

Both points are very important for us to understand the role of a Scrum Master. We must assess our work in these capacities and help the team and other stakeholders to understand both of them.

What is your definition of success as a Scrum Master? Let us know 🙂

Picture credits go to: Search Engine People BlogBrad Hagan and thinkpublic

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us please contact us:

Happiness Index – agile retrospective tool

by Luis Goncalves

No matter how good teams are, there is always an opportunity to improve. Happiness Index is an agile retrospectives tool, which measures happiness of agile teams. Luis shares it in his and Ben Linder´s  book Getting Value out of Agile Retrospectives.

This exercise is a combination of “Develop a time line” and “Emotions Seismograph” from Norman L. Kerth.

What can you expect to get out of this technique

The goal of this exercise is to have a graphic representation of team members´emotions during sprints. This kind of information helps the team to identify what affects its performance during the spring. Whatever problem the team goes through, this exercise helps them to reveal team emotions right in the place.

When you would use this technique

It is certainly suitable for a team that goes through many different emotions (positive or negative) within the sprint. It benefits them when they wish to evaluate the consequences or when the team has several challenges within the spring and would like to understand how these issues appeared.

Happiness Index is suitable for any team, it does not require any specific level of maturity. The exercise can be applied to both remote and collocated teams.

How to do it

Screen Shot 2015-09-03 at 6.12.52 PMTake a A4 white paper and some post-its. Divide the paper in 2 parts/axis – positive and negative. Then divide the X axis in the number of sprint days.

There are 2 ways of doing this exercise:

1) The exercise is done during the retrospective with whole team
2) The exercise is done in small pieces during the sprint

Option 1: Create small groups of 2-3 people. Ask them to do a brainstorming session on events or situations that occurred during last sprint. After, ask the group to create a graphic showing emotion levels with the situations they brainstormed. When all groups are done, create a representation of all groups in a single graphic. Do not forget to put an explanation of each different emotion.

Option 2: Instead of a team drawing the emotion graphic, you should let each individual to draw his own emotion level at the end of each work day. This approach will make sure that all events or situations are covered and are not forgotten.

Both options work well! You will have a great picture of what happened during the sprint. This information helps a retrospective facilitator to identify situations that should be repeated and events that cause the problems or delay in the team. However, you can use root cause analyses techniques to identify the root problems.

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us please contact us: