How to Be a Successful Member of a Scrum Team

“Excellence is the gradual result of always striving to do better.”

-Pat Riley, NBA Executive and Former Coach and Player

While watching agile adoption continue its move into the mainstream over the last five years, I can’t help but think what a marvelous time it is to be in software development. Having worked with a number of Scrum teams as a Scrum Master and now as an agile coach, I’ve seen firsthand the opportunities that opened up for developers, testers, designers and others to become more than they may have thought possible—because for the first time in their careers, they are empowered to be more.

However, every opportunity comes with responsibility, and how well you perform will dictate your level of success. Over the years, I have observed the various commitments that Scrum team members take on.

In this post, I’m going to share with you tips on how to be a successful member of a Scrum team. As you read this, take note of how all the various components of the Scrum framework are interconnected, and provide subtle checks and balances that will aid you in becoming a successful Scrum team member.

Backlog Refinement

Backlog refinement is an ongoing story grooming process that periodically occurs during the sprint cycle. This where the product owner may ask you and other teammates to participate in a refinement session where you will work on a group of stories designated for future sprints.

Your objective will be to use your combined technical expertise to work with the product owner to refine these stories, so that:

The business value is understandable The acceptance criteria is appropriate, specific and measurable The work is doable by the team within a sprint cycle

It is in this process that you actually take part in shaping the future work to be done by you and your teammates. How well you perform your responsibilities can affect your sprint planning.

Sprint Planning

During sprint planning, the core team will plan out its work for the upcoming sprint, which is most commonly a two-week sprint cycle. How well the team conducts its planning will greatly impact the team’s performance in the sprint.

The first item addressed in planning is team capacity. Team capacity is defined as the amount of real time that can be committed to actual sprint work. It excludes vacation, training, meetings, other administrative or operational work, and it also takes into consideration the fact that estimates are good faith estimates and not certainties. The objective is to plan the team’s real capacity based on each team member’s availability during the sprint in order to support a sustainable work pace. So you need to be accurate in estimating your availability. The second item in planning is to discuss the stories brought into the sprint backlog so as to ensure the team has a shared understanding of the work to be done. The team will then break down work for each story into tasks (with estimates in hours) that addresses the stories’ context and acceptance criteria. The task hours are based strictly on team member estimates. The third item in planning is to finalize the number of stories for the sprint backlog based on the stories’ total task hours for the sprint. Should the total hours of the sprint backlog exceed the team’s capacity, the team along with product owner will need to decide which story or stories will be removed from the sprint in order to bring the total story tasks hours in line with the team’s capacity. The final planning item is for the team to conduct a review of all the stories and their tasks to ensure all the necessary work has been addressed, and perhaps have a brief discussion on the team’s work strategy for the sprint.

Sprint planning done well is all about the team taking time to plan for success. Remember that you and your teammates are making a commitment to accomplish this work during the sprint.

The Sprint

One of my high-performing teams often referred to the sprint as the “Quarter Mile.” This was a reference to a movie quote from the Fast and Furious movie franchise where the main character stated that he lived his life a quarter mile at a time.

When I asked for clarification, they stated that all the preparation and planning that the team had done has been for one thing and one thing only: the sprint. And once the sprint starts, you are working and living within the moment—the “Quarter Mile.”

These particular Scrum team members were successful with sprints because they:

Focused only on what needed to be built or accomplished during the sprint cycle Leveraged automated test driven development to improve unit testing and code quality Didn’t wait if they ran into problems; they escalated them immediately and also adjusted their work strategy to continue moving forward Understood the iterative process, and built only to the story’s acceptance criteria, even though it’s not the finished software product Delivered completed stories throughout the sprint cycle, rather than delivering the majority of the stories at the end; this allowed them to make corrections when a story was initially rejected by the product owner and get it fixed and accepted within the same sprint Used pair programming to partner some team members in every sprint as a part of the team’s own cross-functional development goals

I found this paradigm of living in the moment and working only in the here and now to exemplify a core team’s lean and agile mindset when in the sprint. They were not working harder than any other team, but they were working smarter, which allowed them to produce results at a sustainable pace.

Daily Standup

During the daily standup, each team member briefly talks about what they accomplished yesterday, what they’re planning to do today, and what, if any, blockers are preventing them from completing their work.

But the standup is more than a status report, it’s about keeping your fellow team members informed as to what is happening with you (especially if you need help) so that they can adjust and coordinate their day’s work as needed.

Even though the Scrum Master and product owner may be present, you are primarily communicating to your teammates, so talk loud enough so everyone can hear, and be specific in terms of identifying the stories and tasks you are working on as you move them on the board.

Prior to every standup, every team member should have reviewed the board and asked themselves: Are things going according what we planned during our sprint planning?

If not, the team should set aside time after the standup to discuss the concerns and adjust their work going forward. The standup is your primary tool for self-managing as a team during the sprint.

A final note the on the standup: if you cannot attend the standup, you should send an email to your teammates addressing what you would have said if you had been able to attend.

Sprint Review

The sprint review primarily falls under the purview of the product owner. The purpose of the sprint review is to demonstrate working software and obtain customer feedback, which in turn may result in creating additional stories in the product backlog.  

As a core team member, you may be asked to participate in a sprint review to demo a specific piece of software. Here, it is important to remind yourself who your audience is. That audience is usually low-tech, and comprised of the customer and/or managers who have a business-specific need.

So the conversation you may have with your fellow techies regarding the challenges you face building the product is not the same conversation you want to have with this audience. The fact that you are demonstrating working software is a testament to your technical proficiency as far as the audience is concerned.

So it is important to focus your conversation on the business value of what you are demonstrating, because that is why everybody is there. Demonstrating a working solution that solves a customer’s need is what will really impress this audience.

Sprint Retrospective

At the end of every sprint, the team will come together to reflect on the performance during the sprint. This environment is designed to be a safe and blame-free, where the team shares all responsibility.

The focus is not on the individual, but on process and execution improvement. The goal is to objectively learn what the team did well and where they need improvement. I would also suggest that you include the team’s cross-functional training goals as a topic for discussion.

Once this is accomplished, it is incumbent upon the team to select one or two items for improvement and then commit to instituting the necessary changes to the process or execution in the upcoming sprint, and reviewing the results in following retrospective(s).

The retrospective is your tool for continuous improvement and growth as a team, and will hopefully provide the team new ways to inspect and improve how they work together.

On Conflict

Core Scrum teams—even great ones—will experience conflict at times. It’s a given due to the intensity of working together day after day. But, great teams whose members respect, trust and value one another will always try to address conflict in a constructive manner and find ways to move forward.

Being a Successful Scrum Team Member

To be a successful member of a Scrum team, you will need to think beyond your technical area of expertise to be actively involved in a self-organizing and self-managing team.

On occasion, I hear someone remark about someone else’s success in a way that makes it seem it was happenstance: “Yeah, he’s successful, but he just happened to be in the right place at the right time.”

This may be true, but only in rare cases.

I believe that most people who have excelled in their careers are individuals who were prepared and committed to taking full advantage of opportunities presented to them. The same thing can be said for high-performance Scrum teams.

With empowerment, comes responsibility. And every Scrum team member has great responsibility to his or her fellow teammates. Fulfilling those responsibilities will make you a successful member of a Scrum team.

What to Do When the Team Complains About Agile Processes

I recently attended a Lean Coffee event at a Denver-area agile meetup. The group was asked to come up with issues they were struggling with and then, after a vote, we had time-boxed discussions on those topics that generated the most interest.

The topic that I found the most interesting was: What do you do when the team complains about agile processes?

As with most things related to agile, there is no one-size-fits-all answer. What one team may find cumbersome, another team may like.

Almost everyone seemed to have examples, however, of times during which they were on teams that were unhappy about at least some agile processes.


The first thing a Scrum Master, coach or agile servant leader should do when they have an unhappy team is to listen to the team and understand the root cause of the issues they're experiencing.

“Try to get them to understand the why behind the processes,” someone advised. If the team can come up with another way to satisfy the end goal, then maybe it should be explored.

Not only do you want them to understand why processes are in place, but you also want to understand the team’s concerns with the processes.

“Ask several ‘whys’ and get to the root of their fundamental fears,” advised someone from the group.

Examples of root causes seemed to fall into two categories ...

1. Issues with the Tools

In many of the examples that were given, the issues seemed to be related to the tools being used rather than the fundamental agile principles. If tools are slow or filled with heavy processes that take a lot of the team’s time, they aren’t going to like them.

Though we all know that agile promotes individuals and interactions over processes and tools, the reality is that in large organizations, teams often don’t have much control over the processes and tools that are being used. If every team used their own favorite tools and processes, the lack of consistency would cause chaos.

That being said, if tools and processes are creating unnecessary waste, the team might be able to suggest ideas to reduce that waste. The teams may not be able to change which tools they’re using, but perhaps they can work together to come up with some organizational suggestions that could lighten up the processes.

2. Teams Are Not Getting Enough Support

The other category of issues that people brought up related to lack of management support. Stories included teams who were uncomfortable with estimates.

“It took a year for them not to be scared to commit,” said one Scrum Master of a team he’d coached. “As a Scrum Master, you need to help them.”

But how to help them? Again, start by understanding the root cause of why they’re scared to commit. What happens if they miss their commitments? Who holds them accountable and how?

Though agile promotes self-directed teams, the reality is that many organizations are still operating in command-and-control cultures.

The Scrum Master may need to not only coach the team, but also coach management.

There are no easy answers, but start by listening and truly understanding the issues. Then, elicit the help from the team, making sure everyone’s voice is heard.

In the end, you want to empower the team to help solve the problems they’re experiencing.

Is the Product Owner a Member of the Scrum Team?

At the March meeting for the Agile Nashville User Group, we had a lively discussion around whether or not the Product Owner was a member of the Scrum team. This stemmed from a comment about the Product Owner not attending the sprint retrospective since it was primarily only for the team. There were several people on both sides of the issue, each very passionate about their respective stance, so in this article, I thought I would throw in my own two cents worth.

Following "The Rules"

Several people pointed to the “Scrum Guide,” as it clearly states that the "Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master." This is pretty definitive, but still some people pressed the opposite view. There were references made to other organizations such as the International Consortium for Agile, Scaled Agile Academy and the Project Management Institute and their reference materials, which were not as clear cut.

I found this very timely since I had just come back from the Mile High Agile conference where Mike Cohn of Mountain Goat Software had given the keynote, which contained some guidance around just following "the rules."

Mike cautioned that agile practitioners sometimes get too caught up in prescribed rules to the point where they start to blindly follow them. While most attendees involved in the discussion were open to idea of the Product Owner not being on the Scrum team and not attending the sprint retrospective, many seemed to get stuck on what the rules were from the Scrum Guide.

Another interesting thing that coincided with Mike's keynote was the idea of confirmation bias, where we tend to search for or interpret information in a way that confirms our preconceptions.

One of the user group members brought in some research material on this subject at our next meeting. In this material, it outlined what most of the major agile/Scrum organizations stated in regards to the Product Owner being on the Scrum team and attending retrospectives.

The document was well referenced and contained multiple viewpoints, but the section that most aligned with the author's own view was the most robust and annotated. When people with the opposite viewpoint reviewed the content, they tended to focus on the sections that leaned towards their own opinion.

Back to the Basics

When I was asked by several of the group members what I thought, I used the age-old coaching trick of answering a question with a question: "Why do you think the authors of the Scrum Guide clearly state that the Product Owner is a member of the Scrum team, and if it is so definitively stated, why are we still debating it?"

Agile Values and Principles
Now I don't do this just to be a jerk (that is a side benefit), but rather to get people thinking beyond the rule and more about why the rule is there in the first place.

When I train Scrum teams, almost one-fourth of my class is spent on the values and principles from the Agile Manifesto. Often, this is a quick reference slide in some of the training I've seen; but to me, it is at the core of what we adopt in agile – and more importantly, why we adopt it.

Teams definitely should adopt a set of mechanics and rules as part of their process, but these can evolve and change over time where the underlying values and principles remain fairly immutable.

So, let's look at the first part of my question about why Jeff Sutherland and Ken Schwaber decided to state that the Product Owner is part of the Scrum team.

When I look at one of the first principles in the Agile Manifesto, I think what applies is the following: "Business people and developers must work together daily throughout the project."

The Product Owner's job is to maximize the value of the product as the primary representative of the business stakeholders and end users. So if we consider the Product Owner to be one of the "business people," then we want them to work daily with the developers.

In Scrum, developers are part of the Scrum team, so we are saying that we want to have the Product Owner working together daily with the Scrum team. To me, that sounds like they are part of the team.

For another example, take the following principle: "The best architectures, requirements and designs emerge from self-organizing teams."

As the owner of the product backlog, the Product Owner is primarily responsible for the requirements of the product. The developers are primarily responsible for the architecture and design of the product.

As the principle states, we believe that the best way to create these is to have a self-organizing team. Once again, the implication is that the Product Owner is part of the Scrum team so that they can collaborate on these efforts.

Now take our user group's specific issue around the Product Owner attending the sprint retrospective. This ceremony reflects the principle that "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

We can infer from the principles above that the Product Owner is indeed supposed to be an integral part of the team. If we also expect that team to regularly reflect and adapt through the Scrum ceremony of the sprint retrospective, then it is easy to conclude that, yes, the Product Owner is meant to participate.

Why is This Still a Debate?
So if you follow my reasoning above and concur that the Product Owner is meant to be a member of the Scrum team and attend sprint retrospectives, why is this still something agile teams are struggling with?

I find that many organizations struggle with the role of Product Owner, period. They often put people in the role who are not truly empowered to act for the business stakeholders. Sometimes they may put an actual business stakeholder in the role, but they will have competing responsibilities that constantly drag them away from the team.

When this happens, the Product Owner role becomes diluted and stops reflecting the agile values and principles it is supposed to embody. They no longer work with the teams on a daily basis or they cannot truly represent the business stakeholders and become a mere order taker.

The more abstracted from the team they become, the less they are collaborating, and the team will struggle to self-organize around efforts such as gathering requirements. While this can happen on any team, it can be more prevalent in larger organizations where the sheer size and number of teams requires more distributed management. This can easily lead to a certain detachment from the Scrum team for the Product Owner.

When the team feels the Product Owner is not fully integrated into their daily process, then it starts to seem reasonable that they would not be involved in the activities to inspect and adapt that process.

In addition to feeling like the Product Owner should not have much influence into their processes, the Scrum team may also feel a lack of trust that would dissuade this as well. When the Product Owner is farther away from the team and does not have a good understanding of what they do, they tend to make more unrealistic or uninformed demands.

This situation can easily cause friction between the two, and if the Scrum team feels like they cannot openly discuss these issues in a retrospective because of the Product Owner’s involvement, we start to lose out one of the best aspects of agile.

So, Are They a Member of the Scrum Team or Not?
In my opinion, there is no debate that in Scrum, the intention is that the Product Owner is an integral part of the Scrum team. If, in your experience, you feel this not to be true, then I ask you to think about what reasons you have for feeling that way.

What factors are leading you to not want your Product Owner to be in your sprint retrospectives? Investigate those reasons and try to fix the underlying issues to get the team to a place where they would feel completely comfortable with and absolutely want the Product Owner there.

Rather than blindly sticking to a rule one way or another, understand the values and principles behind it, and figure out how better to implement them. Rules are meant to bend, evolve and sometimes even break, but the values behind them will rarely fail you.

To learn more from Tommy, check out his online courses on "Scrum Fundamentals" or on "Advanced Scrum: Requirements Management and Quality Assurance."

Agile Teams: When is an Impediment Just a Complaint?

In Scrum we often talk about impediments: Scrum Masters should remove impediments; team members should raise impediments at the daily scrum; and everyone should make impediments visible, to help get them solved.

Physical impediments are easy to notice and quick to solve. Things like getting hardware for a build server, or getting a whiteboard in the team area.

Other complex impediments like regular production stability issues, or long automated build times are more difficult to solve. They require root cause analysis and a multipronged approach. Often, they are even difficult to identify because people have become so accustomed to them, they no longer even see them as a problem.

What about an organization's cultural impediments?

Recently, we brainstormed impediments with a group of new Scrum Masters at a large corporate organization. Here are some of the things they listed as major impediments:

Some stakeholders are resistant to agile There is a lack of support of agile from management The team lacks the authority to get other departments to work with them The Product Owner tries to control the team too much At first these might look like reasonable impediments. But take another look. Imagine you are the team’s manager or Product Owner, and read them again.

Don’t they sound like the team is complaining? Every one of these "impediments" is about how someone else is the problem.

Can you imagine what might happen if the team made these impediments visible on a whiteboard? Most likely it would create conflict and damage some relationships.

So what can you do instead, if these sound like impediments you have?

Make sure you understand if there is a real impediment to the team, or if people are just complaining Phrase the problem neutrally, without blaming anyone Gather concrete examples and data about how this problem impacts the team Look for solutions for what the team can do to reduce the impact, and ask for help from others to solve the problem together Let’s take the following impediment as an example: “There is a lack of support of agile from management.”

In this case, the team felt this way because the Scrum Master role was not considered a full-time job by management.

The real impediment here is that the Scrum Master role is new in the organization, and therefore not well understood or full time.

The impact to the team is that they skipped their last retrospective because the Scrum Master was too busy with other work to prepare for the retrospective.

As a result, the team did not have an opportunity to discuss a process that was not working for them, and they continued to use this process, causing delays, miscommunication and rework.

Given this impediment, there are a number of actions that can help. For example:

Have the Scrum Master keep a journal of everything they do for a week, and share that in a learning session with others to spread awareness about the role Agree as a team that if the Scrum Master is too busy, someone else on the team will prepare and run the retrospective Run an agile training session for managers to explain the roles in Scrum and why they are important Ask management to try an experiment of allowing one person to be a full-time Scrum Master for 3 months, and assess at the end how it worked Google the problem to see how other companies have solved this Now imagine if I made this impediment and the action ideas visible? Do you think I am more likely to get support?

Going forward, when talking about impediments, and making them visible, focus on the problem and the impact, rather than blaming someone for them. You might be surprised how much easier that makes them to solve.

Remember that there is always something within the the team's control that can be done to help remove the impediment.

Creating Comfortable Workspaces for Agile Teams

Ilan Goldstein is an agile practitioner and thought leader based out of Australia, perhaps best known for his tips on "Scrum shortcuts," a compilation of ideas that became the basis for his published book: "Scrum Shortcuts Without Cutting Corners." 

Ilan talks a lot about the Scrum startup, and the elements that go into making Scrum adoption successful. At the foundation of this is team morale, and he believes that team dynamics and workspaces are the cornerstone for productivity in agile development.

In a field that often casts its professionals into lightless caves in order to toil away in solitude (often by the request of the developers themselves), Ilan argues this isn't always best for the Scrum team. We caught up with Ilan in this interview to hear more on his thoughts around creating a work environment that makes Scrum work better.

With new Scrum teams, how do you help shift the mindset from individual accomplishments or goals to doing what's best for the team?


Ilan: It really is incumbent on the business to communicate and reinforce what is truly important - the creation of quality, working products that delight customers.

Simply put, a product is not built by an individual, it is built by a team. As such, it needs to be appreciated that individual accomplishments are the building blocks that make up the overall team accomplishment; they are a means to an end. 

No doubt, the individual building blocks are still important but it is critical that they are all aligned and supporting one another to create something much bigger and more important then the blocks themselves.

You talk about the physical workspace impacting the Scrum team. Can you expand on that a little here?


Ilan: First, let me say that I couldn't agree more with the truism, "It's the small things that matter." You'd be surprised by how many retrospectives I've witnessed that have been dominated by concerns and complaints about the physical environment.

Whether it's a lack of meeting rooms, limited wall space or microwaves that were bought when Reagan was in office, these day-to-day annoyances can really drag on morale and lead to direct and indirect productivity loss. 

Some of the best environments I've seen haven't necessarily been slick, extravagant settings decked-out with multi-million dollar fittings complete with slippery slides and lava lamps. No, in fact, they've actually been rather economical and grungy; however, they got the basics right and in turn became super-productive yet really comfortable spaces. 

Now if I was to choose one key consistent element of the worst environments I've seen, I would say the least optimal environments are those that impose email as the primary method of communication. This imposition may be due to physical or cultural boundaries but irrespective, relying on an asynchronous and easily misinterpreted communication channel is not conducive to effective teamwork.

What are your tips for changing the way Scrum team members interact with one another if it's a less than friendly environment? 

Ilan: My solution to this problem is to avoid it in the first place. So how do you do this? Well, you hire the right people with the right attitude and you model the behavior that is expected.

I worry about trends in our industry where the focus is on hiring "rock stars" with a total focus and emphasis on technical brilliance as opposed to interpersonal brilliance. The latter brings out the best in others and will ultimately lead to happier and more productive teams.

For more from Ilan, check out his course on Front Row Agile: Scrum Shortcuts