Are We Done Yet?

The definition of done (DoD) is one of the most important and least-understood elements of the Scrum Framework. It is specifically called out in “The Scrum Guide” in what is probably its biggest section, and yet, I’ve seen so-called ‘definitions’ of Scrum that fail to mention it at all.

In this post, we’ll be talking about why, exactly, the DoD is so important. 

DoD Explained

So, what is the definition of done? Fundamentally, it is the Scrum team’s agreement about the standard of quality that it will apply across the product. This concept is closely related to that of the Potentially Shippable Increment that must be created at the end of each and every sprint. The two words in that phrase that the DoD concerns are “potentially” and “increment." 

While all agile approaches – Scrum included – aspire to “deliver early and deliver often,” this does not mean that a product must be handed over to the customer at the end of every sprint. Whether enough useful value has been accumulated to warrant a product’s release is a business decision, and one that is the product owner’s responsibility to make.

If, however, the product is not of releasable quality, then the product owner is effectively relieved of that responsibility. So, scrum requires that the latest increment -- whether it is going to be released or not -- is of sufficient quality that it could be handed over.

What the product owner and the development team are agreeing on when they establish the DoD is the quality bar that will determine what can be shown in the sprint review. You may have heard phrases like “done, done” and even “done, done, done” from some agile practitioners, but in the world of Scrum there is only “done” and “not done.”  

An increment – and that’s the fundamental level at which the DoD works – is done only if it meets the definition of done and can be demonstrated in the sprint review. If it doesn’t meet that standard, then it cannot be shown to the stakeholders.

At the very least, the DoD should mean that the increment has passed all its tests and is fully integrated with the previous increments. In this way, what is being shown is a quality-assured, small and skinny version of the product.


Clearly, the DoD has implications for governance as well as quality. “The Scrum Guide” says that if there are corporate standards in place then they form the default DoD. My interpretation of this is that if, say, there is a company standard for code quality, then that standard should be incorporated into the development team’s practices as well.

Agilists never trade quality for speed, and so we should never lower that standard. In some cases, however, existing corporate standards might get in the way of efficient development. Organizations that use PRINCE2, for example, will often have a phase gate-based governance approach.

Such an approach might work well in a product development that has a high level of predictability, but where there are many unknowns (as in most software development) an approach that is instead based on feedback and responsiveness is needed.

Because of its reliance on predictability, phase gate governance can kill an agile product development. So, in organisations that use phase gate governance, the Scrum team will need to have a conversation with the wider organisation to find better ways of giving stakeholders confidence.


A DoD which clarifies what is needed for the sprint review and which is enacted by the Scrum team accordingly is the perfect starting point for feedback-based governance. Since there is no one-size-fits-all DoD, what the DoD includes is always going to be situational. But, if we accept that the increment must be fully tested and integrated, then several practices naturally suggest themselves.

First, each PBI which makes up the increment will need to have passed both its acceptance and unit tests. Acceptance tests are specific to each PBI, of course, but the DoD will presumably state the policy that all items must pass their acceptance tests to be accepted.

The entire increment will also need to pass integration testing and, as it is unlikely that all the PBIs will be finished at the same time, each of those will need to be integrated incrementally. Therefore, regression and integration testing is strongly suggested at the PBI level. 

In other words, there are implications about workflow embedded in the DoD.


There is yet another aspect to the importance of DoD: the team.

A group of individuals is just that, and can only become a genuine team when it rallies around a common goal. But how can a team meet a goal if they don’t know when their work is finished? 

I once interviewed two programmers on the same team and asked them how they dealt with quality. One of them opened up his IDE and showed me the unit and acceptance tests he ran on his code. The other told me it was the QA department’s job to deal with quality – not his. As you can imagine, this product (and the group building it) did not fare well in the end.

Those were two people with the same functional background-- imagine having a new development team, with all the different skill sets needed to create the product, and no clear DoD. The result certainly isn’t pretty.

Revisiting the DoD

Scrum teams, for various reasons, may not be able to take product increments to a potentially releasable level every sprint. This might be due to the team’s level of performance (if they are a new team, for example), or because the production environment could not be fully replicated in the team’s development environment. 

In this situation, it is important that the DoD clearly indicates where the team’s responsibility ends. Any work that would still be needed to make an increment releasable would be categorized as “undone work” and would need to be listed in the DoD. The DoD would then be retrospected regularly to see what could be moved from the “undone” category into the “done” category as the team takes quality assurance more and more into its own routines.

“Undone” work should not be confused with unfinished work. Work required by the DoD which is unfinished means the item concerned is not “done” and thus cannot go into the review. An item can still be “done” if there is “undone” work.

To understand this, we can think of there being two quality bars: one for the sprint review and one for actual release. The gap between them is the undone work. In committing to any sprint goal, the team is implicitly committing to the DoD as well.

However, it is not committing to do the work listed as undone in every sprint -- that work will be done just prior to an actual release The development team’s job is simply to get the increment to “done,” and the product owner then decides whether the PBIs that are part of it can be accepted as complete.

So what happens if an item shown in the sprint review is rejected as not fit for purpose by the customer? The answer is that, since it passed the scrum team’s standards, it remains ‘done.” If the product owner believes the requirement still has value, he or she will put it into the product backlog as a new item and it will be prioritized accordingly. But, of course, the team should still reflect on what has happened, and may well strengthen the DoD to reduce the chances of “done” items being rejected in the future. 


So far, we’ve seen that the definition of done is important for: 

Product-wide quality standards Governance Workflow and engineering practices Team-building

We’ve also seen that Scrum teams need to revisit their current definition of done on a regular basis to strengthen their assurance of the product’s quality.

If you can think of any other things that the DoD is important for, feel free to let me know in the comments section below. And with that, we’re done.

The Scrum Task Board and the Self-Managing Team

In the early days of Scrum, the quickest way to locate a Scrum team’s work area was to look for the task board, which was usually mounted on a nearby wall. Work was managed using index cards, sharpies and spreadsheets, and the task board served as a tool for tracking work as well as an information radiator.

Anybody walking by could simply look at the task board and see the team’s progress at that point in time without having to ask a single question.

However, what inevitably happens in nearly every field is that new technology and tools are developed over time with the intention of “making it easier” to manage work, and the world of agile is no different. Some tools were built from the ground up to manage agile project work, while others were developed as add-ons to existing tools.

When an agile project is just beginning, it seems like the first question asked is always “What agile tool are we going to use?” Let’s face it, we in the IT industry love our tools, and I am no exception.

However, the technology we perceive as progress can sometimes have unintended consequences. Take, for instance, society’s extensive use of social media, texting, and other technological forms of communication. They were originally created to save time and effort, but we are only now discovering that these tools can lead to a sense of social isolation in certain segments of the population.

High-Tech Tools: More Harm Than Help?

So, what does this have to with Scrum teams? A Scrum team’s success is all about collaboration, which in turn is all about co-location and face-to-face communication. While technology can certainly enhance a distributed Scrum team’s collaboration, it also has the potential to hinder a co-located team: if the team relies too heavily on technology, it can start to act as an inadequate substitute for face-to-face communication and collaboration.

For example, I was working with two Scrum teams over the course of many sprints and, while all their information was readily available in a high-tech agile tool, I rarely saw it displayed on anyone’s screen. I also noticed that their stand-ups were functioning as more of a status report than an opportunity for the team to share information and level-set the team’s progress in the sprint. 

Although the team reported a high level of confidence in completing stories during the mid-sprint, I could see from the story point burn-down chart that they were scrambling to complete stories in the later stages of the sprint. I knew that all the team members were solid professionals, so their work ethic clearly wasn’t the problem.

Eventually, I realized that, while they may have been focused as individuals, they weren’t focused as a team. I also realized that the unintended consequence of technology was that the team’s most crucial information was buried in a tool that no one bothered to access.

A Low-Tech Solution

Since I didn’t have two 70-inch monitors to put in the team rooms, I decided to go old-school. So, the next day I came in with painter’s tape and put a task board on the wall. I then printed out the stories and tasks from our agile tool and recreated the task board to reflect the status of the sprint.

I told the team that, during the sprint stand-up, each team member would go to the task board to address the team. I also told them to focus on the team and ignore anybody else in the room, and that each time they spoke about a specific piece of work they would need to move the corresponding tasks on the board to the appropriate columns as well.

It took some time for them to get comfortable with doing the stand-up in this way, but the result was that the task board started to provide them with the focus they needed as a team. It had a constant presence, easily showed the team’s progress and gave each team member the satisfaction of physically moving their work across the board from the “to-do” column to the “done” column. 

During the mid-sprint checks, the accuracy of the team’s confidence level vote increased dramatically. And, when a mid-sprint check indicated that the team might have a problem, they used the task board to determine how to resolve the problem and re-allocate resources accordingly. For these teams, as well as many others, the task board quickly became their primary tool for self-managing.

The Value of Planning

I always tell my teams that the most important aspect of sprint planning is not the plan itself but the fact that they engaged in the act of planning in the first place. This is because the act of planning gives the team a shared understanding of what must be accomplished.

And, given that things rarely go according to plan, we must constantly re-plan “in light of what we know now,” and every team member should be fully aware of the changes in the revised plan. With the help of a humble task board, teams can easily collaborate, re-plan and focus for the duration of a sprint, and that’s the sign of a truly effective agile tool.


You Need a Scrum Master

“We can’t afford a Scrum Master.”

“What does a Scrum Master do other than schedule meetings?”

“Any developer can call themselves a Scrum Master and send meeting invitations!”

“We don’t need a Scrum Master, we do things differently!”

These are some of the statements often heard from management when asked whether they need a Scrum Master on their teams. These types of responses could reflect some of the misconceptions about the value of the Scrum Master role, and might also reflect a previous, unpleasant experience with an incompetent one.

Although this question has been asked several times in various agile blogs and has been answered with a clear “Yes” in almost all of them, it is still being asked every now and then, especially by smaller companies and startups. Some other arguments on this topic can be found here and here.

In this post, I would like to share two situations faced by friends of mine in two different companies which both decided against having a dedicated Scrum Master on their team.

The Team Lead/Scrum Master Knows All 

In a previous post, I shared my concerns about mixing roles in a scrum team, and sharing the Scrum Master role among developers was one of them.

In this real-life scenario, a developer (or the tech lead, to be more specific), was given the title of Scrum Master since he was “certified.” But, if we look at the team’s internal process, we will soon discover why such a team needed a dedicated Scrum Master.

In this team, they didn’t have sprint review meetings, the “daily” Scrum was done three times a week, there were no retrospectives or build automation and the tech lead was the only one doing code reviews for the whole team. It’s easy to imagine the massive queue of tasks that were waiting for review and deployment. The technical debt needed months to be fixed, and the product owner was anxious to get the features to production.

This team sorely needed a dedicated Scrum Master to coach the team on the value of core agile practices such as pair programming, automated tests and automated builds. Essentially, the team needed to understand the importance of collaborative code ownership as well as the power of frequent deliveries and early feedback.

We Don’t Need a Scrum Master

This next team was a small one, but the takeaway is similar to that of the first example. This team didn’t have a Scrum Master at all, and instead had a product owner, a distributed development team and a team lead. Like the previous example, the team lead was the only person who reviewed the code, which quickly created a lagging queue of tasks. Another challenge for the team was that some members of the development team were part-time employees, while others were dividing their attention between two projects simultaneously.

Some might wonder what a Scrum Master could possibly do for such a team. In short, a Scrum Master could act not only as a glue holding the team together but also as a grease to help the team get through challenges more smoothly. He or she could help the team organize themselves properly, improve communications, help the team share knowledge and improve code ownership.

In both cases, the lack of a Scrum Master increased and complicated the difficulties the teams faced. Without adequate understanding from management of the importance of such a role, teams like these will continue struggling to find their way and provide high-quality products.

Do you have other examples of a lack of a competent Scrum Master making a team’s life more arduous than necessary? If so, please feel free to share them in the comments section below.

Leadership & Effective Decision Making on High Performance Teams

Trust, Vision and Ownership

In a previous post, I identified "3 Necessary Conditions for 'Going Agile'": Trust, ownership and vision. There, I used up my quota of blog space by focusing on trust and its impact on a high-performance team.

Here, I will continue that voyage by exploring ownership.

High Performance Defined

To get started, here’s a definition of a high-performance team from Wikipedia:

A high-performance team (HPT) can be defined as a group of people with specific roles and complementary talents and skills, aligned with and committed to a common purpose, who consistently show high levels of collaboration and innovation, that produce superior results. 

Common characteristics of HPTs include:

Participative leadership Open and clear communication Clear goals, values and principles Mutual trust Managed conflict Flexibly defined roles and responsibilities Coordinative relationship Positive atmosphere Continuous improvement

Nice, right? Who wouldn’t want to have more of that in their organization?

Delegation and Decision Making

With the characteristics described above, ownership of and attention to results is distributed as equally as possible. To accomplish this, decision making is taken up by various team members so that “the call” is no longer the domain of any single individual, especially not “the boss,” because command and control is simply too slow.

Distribution of decision making, aka delegation, is a great deal more than “Either you do it or I do it.” To avoid that mindset, I coach my teams to experiment with a matrix that provides four types of delegation:

Type 1: Decisions that only the leader can make/take - Type 1 can be made with or without consultation/discussion/buy-in with/from the team, though consultation is of course preferred. Type 2: Decisions that individuals/the team can and should make/take themselves, but need to first run by a leader - In the event of a “tie” or a disagreement on how to proceed, the individual/team calls it. If the individual/team is not willing to take accountability, then it reverts back to a Type 1; there is no “Type 1.5.” Type 3: Decisions that individuals/the team can make/take themselves, and inform the leader of after the fact – These decisions can be made either “contemporaneously” or “routinely.” Type 4: Decisions that individuals and team can make/take themselves. In other words, the “Just do it” method.

Technically, there’s a fifth type as well:

Type 5: Wait until you are told what to do by the leader.

We don’t want Type 5 to be an option. Why? For a boatload of reasons, including these: No one person can know as much as a talented team, and being told what to do demotivates talented individuals and removes accountability.

Where is the Team Today?

To begin the distribution journey, start by developing a picture of your team’s present conditions. Grab the team and the leader, a pad of post-its and some pens. Crowd source a divergent list of all the decisions that need to be made over the course of the coming month. Have an unfiltered brain dump and fill the white board.

Next, affinity map the individual decisions to converge on topics and themes. Using those groups, build a matrix, placing topics/themes/details in rows and each of the four delegation levels in columns.

Then, like planning poker, have each team member pick a number from 1-4 to indicate what type of decision they think should be applied to the topic at hand today. The range of votes may or may not surprise the participants.

Then, discuss the results and see if both the team and the leader can agree on “where things are.”

Newly formed teams typically start off heavily skewed with lots of Type 1’s, and maybe a few 2, 3, or 4’s, while more experienced teams tend to have a more even distribution of all types.

Envision the Future

Once both the team and leader have a picture of where they are today, rinse and repeat the poker rounds for where folks want to be in the not-too-distant future, like the next sprint or the end of the next quarter.

As a team matures and becomes more gelled and performant (retrospectives help on this path), things should move as far to the right of the matrix as possible. Loads of type 4’s, 3’s, a few 2’s and almost zero 1’s is ideal.

Why? Because moving decision-making deep into the team and away from “the boss” reduces bottlenecks and wait times, reduces waste and multiplies by orders of magnitude the speed at which a team can move, experiment and learn.

Put a date on the calendar to do this exercise again, perhaps in three months. A team and its leaders should be careful not to build the future state matrix once and then never revisit it out of a misplaced need for consistency or a fear of stretching out of their comfort zone. Instead, remember to regularly inspect and adapt. 

Group Decision-Making Models

As decisions move into the realm of the team, a common issue that comes up is how exactly they should go about making them without resorting to asking the leader: “What should we do about this?” (by the way, if you are a team leader and you hear that question too often, try simply answering with: “What would you do if you were me?” More on this approach here.)

There are many models that can help a team choose options when it comes to team decision types 2, 3, and 4 (consult first, inform after or JFDI, respectively). None of these models are perfect, and each has its own strengths and weaknesses:

Consensus – A collaborative approach. Typically requires that the majority approves, but also that the minority agrees to go along. In other words, if the minority opposes the idea, consensus requires that it be modified to remove objectionable features (see: Fist to Five). Since everyone gets a voice, consensus is both useful and appealing, although it is also potentially dangerous. It can quickly devolve into a battle for who is willing to argue their point the longest, or a watered-down compromise. Advice – A simple form of decision making where any individual can make the call. But, before doing so, they must seek advice from all affected parties as well as those with expertise on the matter. The individual, however, is under no obligation to integrate every piece of advice they receive. Random – The group leaves the choice to chance. Put the options in a hat and pull out the winner, roll the dice or flip a coin. Unanimity (or “12 angry peers”) – The group discusses the issue until an agreement is reached by all those involved in the situation. I Can Live with It – Anyone might have well-reasoned objections to a given decision. However, they agree to work toward the goals of the decision anyway. Solidarity – Unwavering commitment wherein individual will is suppressed for “the good of the group.” Rock Paper Scissors – See “Random.” :) Experiment

Different decisions call for different decision making models and types of delegation. Some teams may not be ready for all of the types covered above, and not all types are the best fit for any given team.

For best results, try to come to an agreement on the following:

(Type 1, 2, 3 or 4, or any other nomenclature that fits your culture) Which one will be used for the decision at hand today Which one the team wants to use tomorrow

See what works, see what doesn’t and continuously improve. Not only will the team experience a significant increase in productivity, but there will be a greater degree of trust and innovation as well. Once again, that is the promise of truly embracing agile.

Linguistics in Agile: Top 10 Anti-Agile Terms

Agile practices have introduced a new lexicon for people to absorb and understand. Happily, along with the useful terms comes a more entertaining vocabulary.

Here are my top 10 favourite anti-agile terms:

Agile in Name Only, or AINO: Companies that have adopted agile frameworks and practices without embracing the cultural changes required. Dark Scrum: Abusive forms of Scrum, where the framework is misapplied to oppress and exert power over developers. Ron Jeffries introduced this term in September 2016. FrAgile: Agile practices that are performed without rigour or discipline. FrAgile provides an excuse for poor quality development that avoids accountability. Lipstick Agile: Agile practices cosmetically applied without any understanding or noticeable difference to the true nature of development. In other words, you can put lipstick on a pig, but it will still be a pig. ScrumBut: Scrum is "adopted," but dysfunctions are accepted by the team as the standard way of working. The syntax for this is (ScrumBut)(Reason)(Workaround). For example, "We use Scrum, but we have thirty-four people in our development team because we are working on a complex project.” Scrumdamentalist: An evangelically pure follower of Scrum practices who operates from an ivory tower, typically with a two-day CSM "qualification" and no experience. Essentially, scrumdamentalists have no sense of reality. TrAgile: Tragically implemented agile frameworks or projects that end in tragedy. In these situations, agile practices are nominally in place but without true understanding or tangible improvement. For example, daily Scrums which contain 32 people, last an hour and consist of everyone giving a status report according to a Microsoft Project plan. Wagile: A hybrid of waterfall and agile development practices resulting either from desperately trying to save failing projects, or from slipping back to waterfall from agile. By completing several short waterfalls, teams delude themselves into thinking that they are agile. At best, this adds shorter iterations, agile walls and daily meetings to failed waterfall projects in an attempt to reduce overall risk and appease management. Water-Scrum-Fall: A failed implementation of agile where requirements gathering is completed first, and teams then perform the implementation before the results are passed to the deployment team for eventual release. Zombie Agile: A blind adherence to agile practices without adopting the mindset required to make them work.

Please tell me about your favourite agile (or anti-agile) term in the comments section below.

#NoEstimates: Crazy Talk, or Agile Compatible?

A couple years back, I started hearing about an interesting movement in the software and web development community called #NoEstimates. At the time, I was fresh out of CSPO and PMI-ACP certifications, and I naturally started wondering about this movement that was too new to be taught by the courses I took to earn those certifications.

I had colleagues who were adamant that we avoid estimates in most cases, while others insisted it was insane to suggest that accurate estimates were not always necessary or possible. Before forming my own opinion, I decided to examine as many sides of the discussion as I could and read up on the thoughts of various writers and experienced professionals in the community.

What I found were well-reasoned arguments on both sides. However, one thing that bothered me was that people who did not favor implementing a strictly defined agile framework didn’t tend to want strict estimations either, while those who wanted to implement a more elaborately defined agile framework also tended to support formal estimates.

It made me wonder – can #NoEstimates and agile coexist in the same team? Did being agile and Scrum certified mean that I automatically needed to reject and exorcise our team from this dangerous school of thought? I didn’t think so.

Don’t get me wrong – Scrum and other agile frameworks explain a thoughtfully evolved process for estimation that is rock-solid, clearly defined and often 100 percent part of the framework. However, not all agile frameworks are the same. Many teams use formal estimates with great success, and I want to be clear that I’m not advocating that there is one correct answer for every team.

The only thing I’ll advocate in this debate is to consider reasoning from all sides. To help facilitate this, I’ve prepared some points that are inspired by some respectful and intellectual discussions I’ve noticed on LinkedIn, various web development blogs and conversations with other professionals.

Below is a summary of some of the points that have stood out to me from the various discussions. Of course, this list does not contain every point that can possibly be made, so feel free to share your own points and express your own opinions in the comments section at the end of this post.

Points Supporting Less Emphasis on Estimates
For some teams, estimates are often inaccurate. While teams attempting to adopt Scrum and other estimate-supported agile frameworks will probably want to refine and improve their estimation process before abandoning it, some experienced programmers have found that the teams they work on over the years tend to have inaccurate estimates. They point out that these estimates often err on the side of over-optimism.
Some people intentionally provide inaccurate estimates. Some people believe in overcompensating, for example doubling their initial estimate to create a timeframe that’s twice as long. While this might ensure that fewer estimates are overly optimistic and fewer deadlines are missed, this can be problematic if the goal is to coordinate with other teams like marketing and sales, who might be caught off-guard by an earlier-than-expected release.
In many cases, accurate estimates are too difficult to provide. For example, if you’re being tasked with building an integration with a system or API you have little experience with, it could be challenging to form an accurate estimate. A lot of research would be needed, and necessary documentation could be inaccurate or lacking. There could be other factors, like the quality of libraries or wrappers provided for various programming languages, API stability, ongoing support and security, which could also affect an estimate’s accuracy.
Estimates are often misused. Rather than viewing estimates as a basic guess, teams can be tempted to treat them as hard deadlines complete with budgets assigned and people held accountable. Similarly, stakeholders often express disappointment when finished work isn’t delivered per the original estimate. In the very worst cases, teams are punished for needing more time than originally estimated, which can lead to a demotivated team, less accurate work and even less accurate estimates.
Estimates don’t make work ship faster. Any given work takes a set amount of time to complete, regardless of the estimate applied to it. The process of estimation, justifying estimates, explaining why actual work time varied from estimates and all other estimation-related activities can serve to slow down the team’s ability to ship work and deliver value.
Some teams become too focused on estimates rather than prioritization, scalability, careful scoping or other factors. Some teams divert so much attention to delivering per the estimate that they make sacrifices in other areas, like scoping the work carefully or making sure the work is scalable. This is harmful for the product and potentially delivers less value long-term. Points Supporting More Emphasis on Estimates Estimates can be made accurately, and there are ways to increase accuracy. The more you estimate, the better your estimates should become. Eventually, you can compare upcoming work to a larger historical data set of previous work performed by the same or similarly skilled and experienced team members. The more historical data you have, the more accurate your estimates will be.
Other teams need to plan business decisions around estimates. Marketing teams need to know when to launch marketing initiatives around major launches or updates, and sales teams and customer success teams need to know which features will be available, and customer support teams need to be staffed properly for a large release. No team wants to feel like they’ve wasted time and efforts by preparing for the wrong date, and they also don’t want to miss major opportunities by arriving late to the party.
Estimation can help set more realistic expectations. Some other team members or managers might take it upon themselves to assume how long work should take. Wouldn’t you rather set the expectations with your own estimation rather than open the door to other estimations from people who haven’t studied or scoped the work as carefully?
Estimates do not mean your workflow cannot be continuous. If you finish early in the sprint, you can pick up future sprint or backlog items that fit into the remaining time. How do you know they fit into the remaining time? They’ve already been estimated! In this way, estimates do not need to reduce work efficiency.
You need at least some kind of estimate to do an effective cost-benefit analysis. How can you know if it’s even worth doing the work if it could potentially take so much time and money that the costs outweigh the value delivered? How do you know this work is more valuable to pursue than other work, if you don’t estimate how much effort each is required to complete? Imagine agreeing to have a plumber fix a dribbling sprinkler head with no estimate and then learning the cost will amount to your entire life savings.
Estimation can reveal inaccurate expectations with burndown charts and other tools. Burndown charts can help show if work is proceeding at expected paces or if it looks like scope, time or budget will need to be adjusted to ensure success. This can be done without punishment for inaccurate estimates, but simply by responsibly tracking progress and comparing to customer expectations. Identifying any significant discrepancies early on can help moderate and readjust expectations to avoid unpleasant surprises.

Again, this list is not exhaustive, and not all points will apply to all teams. Some of these concepts may seem like they’re taken to the extreme, but I’ve personally seen, heard and read these exact concepts from real teams and professionals. Please share your own opinions and experiences in the comments section below, and let me know what you think about the value of #NoEstimates.

From Scrum Master to Product Owner: A Journey

Many of us have transitioned from either a sofware engineer role or a QA engineer role to a Scrum Master. This is a natural path for those who want to become a servant leader, working with the teams/stakeholders, coaching people and leveraging agile/Scrum across the organization. Furthermore, it requires a different mindset with more focus on soft skills.

It’s also common to see software engineers and QA engineers turning to a product owner role.

Therefore, how difficult is it to be a product owner when you are a Scrum Master? Well, there are a lot of challenges, due to the fact that these two roles have different perspectives and skill sets.

Scrum Master: Abandoned and Chosen

Once upon a time, a company I worked for as a Scrum Master decided to get rid of all Scrum Masters for various reasons—the most critical being budget.

Consequently, the role of the Scrum Master merged with the engineering manager, and the engineering manager took over the Scrum Master’s responsibilities. As usual, some of the engineering managers weren’t prepared to assume this new role because either they were toxic to the teams or hadn’t been trained enough in Scrum.

At the same time, all Scrum Masters were laid off by the company due to major cuts on the budget, my boss asked me if I would like to become a product owner once the team I was acting as a Scrum Master for didn’t have a full-time product owner.

I was already doing part of the product owner duties: working with the stakeholders to gather the requirements, writing and prioritizing the user stories, digging into the product and envisioning its growth, working close with the teams, and being the voice of the customer.

The team’s product owner was so busy with another priorities that she didn’t have enough time to focus on that particular team. I took the initiative and action on behalf of her.

A desire to deliver a delightful product to my customers was always on my mind. With a lot of excitement and anxiety, I finally accepted the challenge of officially taking on the role of the product owner.

New Journey: Ups and Downs

Several Scrum Masters like me have faced many challenges with their product owners and sometimes they become the impediments for the team. As a Scrum Master, we should address and remove them.

As the first time as a product owner, I didn’t want to be the impediment and cause of the difficulties for the team. As a product owner, I wanted to create the user stories using the INVEST model, write good acceptance criteria, groom the user stories with the team, prioritize the backlog, be available to the team, define a goal for every sprint, and so on.

I was doing my part, however how about the Scrum Master (in fact, the engineering manager) for the team and product? Well, she became the impediment, because she was not doing her part.

I was frustrated due to the fact Scrum was not being implemented as it should be and the whole benefits were being lost. The team was still looking to me, waiting for me to remove this impediment, but I wasn’t supposed to take action anymore, only concentrating on the product.

On the other hand, I was the Scrum Master before, so I still had the ability to coach the new Scrum Master, no excuses. However, the engineering manager didn’t want to follow coaching and I was reprimanded when I was told I was on the product side and couldn’t influence the engineering process anymore.

This is the hardest part of converting from a Scrum Master to a product owner role: your brain has to do a mind-shifting and move away from the old habits and responsibilities.

For several months, I continued facilitating the sprint planning and review, because the Scrum Master didn’t want to do that or didn’t know how to do it, but the product had to be delivered anyway.

Resilience and Working Hard for the Team and the Customer: Reward

It might take time, but you can adapt yourself to the new norm from Scrum Master to product owner. In the beginning, the path seems long: our focus is different, more on the business side, staying closer to our customers, and understanding their pain points.

If you’re faced with this challenge, don’t give up, make all your efforts to switch gears and mindset, and the reward will come.

What did I learn? Make the team feel part of the product, and they can help you to drive the results and goals of the company. The team will support you in the process for a while if you are open, transparent and trust them.

Be present in every retrospective and ask how you can improve in a very honest conversation.

Be humble and listen. Change your attitude, demonstrate that you’re working hard not only for the success of the product, but for their success as well.

As a new product owner, learn every piece of the business rules, talk to the stakeholders, create effective roadmaps and be the “CEO of the product.”

Last, but not least, go to conferences, training, read books about product management, be involved in the agile community. It’s now time to focus your knowledge and strengths in the product ownership.

New Hope: Continuing the Journey

New challenges appear every day and this is a good sign because the world keeps evolving and each challenge is an opportunity to grow in your career and as an individual.

Improve the method of creating the user stories, leverage the product, streamline the process of delivering the features continuously, go outside of the building and listen to your customers, experiment new things and finally delight your stakeholders with innovative products.

The path and the migration from a Scrum Master to a product owner can be complicated; however, it’s rewarding and valuable for several reasons: business model understanding, value proposition creation, industry standards and terminologies in practice, customers and partners relationship, channels and segments applied, generating revenue by different methods, applying innovation and open new markets, and the list goes on.

Are you also transitioning to a product owner role and need some help? Feel free to leave your comments or questions and I’ll be glad to help you out.

How to Get Your Teams to Estimate Better

“We need to get better at estimating,” an experienced member of a Scrum development team once told me. “Management is getting concerned that we keep coming up short on our commitment.”

“Really?” I responded. “What have you been committing to?”

“Thirty story points” she said. “We get there about 50% of the time. In a couple of recent sprints, we’ve even exceeded thirty points, but the last sprint marked the third time this quarter that we fell short of our target.”

“Why was your forecast off target, do you think?” I asked.

“Well, things come out of left field occasionally. You know, stuff that couldn’t be anticipated in sprint planning,” she answered.

“So, why are you estimating effort if you can’t predict what will happen in the sprint?” I said.

Now, at this point I want to make clear that I am not one of those who say that development teams should not estimate effort. For me, the ability to estimate independently is an important part of the autonomy of teams. What I was trying to do in this particular conversation was to get the team member to consider why teams estimate in the first place, and what “commitment” means in that context.

It is not just a matter of those doing the work being the only ones who are able to estimate effort, which I believe to be true. I recently participated in a large multi-team project of effort being estimated by a centralized systems analysis unit. In that project, the development teams were involved in estimating, but it was the systems analysts’ forecast that was being communicated to the customer. The result was massively inflated customer expectations, and retrospection revealed that the teams’ estimates were about four to five times larger—and thus far more accurate--than those of the analysts.

Why Estimate Effort?

So, development teams make the best and most accurate estimations. That’s all well and good, but it still doesn’t answer the question of why estimates are necessary in the first place.

Scrum is a “pull” system in that it balances demand with the team’s capacity to do work by giving the team control over how much work is brought into the sprint. No one can tell a development team how to do its work, or how much work it must do.  Effort is estimated – in story points, in the number of stories or in person-hours – so that a judgement can be made about how much work can be pulled in from the product backlog in order to meet the sprint goal.

When either team members or their managers start to fret about the team’s commitment in terms of its target velocity, it is a sure sign of old muscle memory kicking in. After all, the velocity is a forecast, not a commitment. The team’s commitment is not to its velocity but to the goal that was agreed upon in the sprint planning. And, in any agile environment, commitment means that, given the information we have right now, the resources we have at our disposal and our judgement about our capacity to do work, we think we can get to a certain point by the end of the sprint, and we are going to do everything in our power to get there.

Therefore, a commitment can never be equated to a guarantee. It is akin to the moment a football team walks onto the pitch: the team is committed to winning the game, but there are too many variables in play (not the least of which is the opposing team!) for victory to be guaranteed from the start.

When managers ask me questions about the target velocity of the teams, my first response is to ask them why it should be any concern of theirs. They typically mumble a reply about making sure the team is working to plan, or being efficient. A brief chat normally follows in which I point out that management’s concern should be with business outcomes and with making sure the teams have the environments and tools they need to deliver them, not with the team’s tasks.

Target Velocity and the Sprint Goal

So, at this point we’ve established that target velocity is a concern of the development team and no one else (OK, the product owner needs to know about velocities so he or she can make trade-offs in the ordering of the product backlog, but that’s another story entirely). Estimates simply need to be accurate enough for the team to confidently identify the items at the top of the product backlog that can be worked on to meet the sprint goal.

A good product owner will give the developers extra wriggle room by articulating the sprint goal to customers and stakeholders independently of the product backlog items (PBIs) or the stories that might constitute it. By giving the upcoming increment a named state, or by describing the expected value in a few sentences, the product owner can work with the team if a mid-sprint descoping of the forecast is needed, without compromising the sprint goal.

All of this means that while the team’s estimates do not demand the same precision as task estimation in waterfall-based planning, they do still need to be accurate. Actual velocities that go up and down like a roller coaster help no one, and some level of predictability is needed. I’ve seen teams agonize over what a 13-point story should look like, and have even been shown handbooks in which reference PBIs are described for each number in the Fibonacci series. In my experience, this type of overly complicated approach never works.

"Smaller" is More Predictable

There is only one way to improve the estimate of effort for PBIs: breaking them down into smaller PBIs. Think for a moment about the values most often used in planning poker, for example: 1, 2, 3, 5, 8, 13, 20, 40 and 100. They loosely follow the sequence in which each number is the sum of the previous two.

This raises the question, why “20” instead of “21”? Simply, because “21” would be too precise. In effect, we are saying that anything more than 13 can be considered large, and will probably need to be decomposed.

The larger numbers in the sequence and, more specifically, the larger gaps between them, reflect a corresponding level of uncertainty. Suppose the team thinks a PBI is bigger than an 8, but is probably not big enough to be a 13. In that case, it might “precisely” be a 9, 10, 11 or 12. However, they can only categorize the PBI as either an 8 or a 13. Essentially, the larger a PBI is, the greater its possible variation from its predicted effort. On the other hand, if all the stories are, say, a 5 or smaller, then it is only when a PBI sits between a 3 and a 5 that you begin to see significant variance.

It doesn’t really matter whether the team uses stories and story points or not, as long as the underlying goal is still the same: to break the PBIs down to the smallest size they can be and fit a number of them into the sprint. In my view, this is the only way that a team can reliably improve the accuracy of their estimations.