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.


Agile Transition Strategy

In May 2015, I attended Jeff Sutherland’s “Getting to Done” presentation at the DC Scrum Users Group meetup. During his presentation, two things really grabbed my attention.

The first was the Standish Group’s 2011 CHAOS Report, which revealed the percentage of successful, challenged and failed projects using either waterfall or agile methodologies. The second was Sutherland’s statement that “as larger companies adopt Scrum, the percentage of successful agile projects will drop.”  

For the purposes of their report, the Standish Group defined project success as being delivered on time, staying on budget, and reaching completion with all planned features intact. In their 2015 CHAOS Report, they published their findings on the state of waterfall and agile projects that were conducted from FY2011 through FY2015. The results of that report are shown in the table below.

Overall, successful agile projects only dropped by 3 percent, while challenged projects increased by a corresponding 3 percent. However, the more startling statistics begin to become apparent when looking at the success and failure rates of small projects versus those of large projects. 

Small agile projects were approximately three times as successful as large projects, while the failure rate of large agile projects was almost six times greater than that of small agile projects.

In light of this data, the question remains -- why is this happening?

My thoughts are (1) large organizations are feeling the pressure to adopt agile methodologies and do it quickly for fear of being left behind by their competition, (2) large organizations tend to underestimate the level of commitment and effort it takes to successfully transition to an agile environment and (3) they fail to realize that a successful transition is not going to happen overnight.

So, if small agile projects are three times more successful than large agile projects, why not incorporate the advantages of small projects into your organization’s agile transition strategy? Why not transition to an agile environment using a series of small transitions and rolling wave planning?

The advantages of doing so include not taking on the entire organization all at once, spreading out the cost over a longer period and having the freedom to make initial mistakes on a smaller scale with little to no large-scale repercussions. And, as you learn more, each subsequent transition will naturally progress more smoothly than the one before it.

When planning the transition series, consider the composition of your organization’s population. Every organization has three major profile types within its population. 

Those three types are:

Early adopters: These are the kindred spirits who are most receptive to moving forward with new and innovative methods. The silent majority: The mainstream folks who need to see solid evidence of success before embracing a new way of working. The Resistance: Those who are decidedly in favor of the status quo and are neither interested in nor comfortable with change. Their favorite quote is likely to be, “But we’ve always done it this way!”

Execute your strategy in the same order, starting with the early adopters. As you execute your transition, make sure to capture pre- and post-transition metrics as well as the user experience for each project. Then, make sure each project success is widely publicized and that the people who worked on those projects are recognized. 

Repeat this process for each profile type. This will give you the opportunity to build your case for transitioning to an agile environment while simultaneously fostering ground swell.

Using a transition strategy that incorporates this approach lets the organization publicize the fact that they are successfully transitioning to an agile environment, while doing so in a manner that will allow both the organization and its people to truly reap the benefits of a real agile environment rather than an environment that is “agile in name only.”

How to Build and Motivate Your Scrum Team: Part 2

In part one of this article, we took into consideration the group’s past project experience and focused on laying a foundation for shaping this group into a Scrum team. We addressed how we made the initial logical and emotional connection with the group and took the first steps in empowering them. 

We now continue the journey and discuss how to build on this foundation as we guide a team through the adoption of the Scrum practices.

My Sprint Cycle

I always use the two-week sprint cycle for my teams unless circumstances dictate otherwise. However, I structure the sprint cycle with one preparation day (also known as a lag day) and nine working days. The preparation day is the first day of sprint, where I schedule the sprint review, followed by the retrospective in the morning and sprint planning in the afternoon. 

The reason for this is that it better ensures the retrospective is done regularly. The retrospective is your primary tool for building this group into a team and helping the team to continuously improve. 

But, I have often seen situations where the retrospective fell into disuse because the team felt they were behind in their work and didn’t have time to spare. I’ve also discovered that since the team is doing something entirely different for the day, it provides them a mental break from the rigors of the nine working days.

The Journey Line

Since the first sprint does not require conducting the sprint review or retrospective, I generally utilize this time to conduct a journey line exercise as described in Lyssa Adkins' book: “Coaching Agile Teams.”   

I have each person draw a journey line of their career on a large sticky pad sheet. I ask them to start at whatever point they want to and take it to the present day. If they ask for suggestions, I generally tell them to start with high school, college or a point in their life when first they developed an interest in IT. However, before I ask them to do their own journey line, I first share my own journey.

The intention of this exercise is to learn about the skills, experience and knowledge they garnered along the way and share what they bring to the team. They are given about 20 minutes to complete their journey lines and then place it up on the wall. Then each person will talk about their journey with the group.

While each person is presenting, I have the rest of the team take notes on the skills, experience or knowledge most relevant to the current team's work. At end of each presentation, each person in the audience will then read aloud their notes and stick them up on the presenter’s journey line.

At the end of this session, I ask them to come up with a team name and avatar that the whole team can agree upon, and we finalize their decision during our first retrospective. I feel that a team identity is critical to the team-building process. Once a name is chosen, from then on, I always address them by their team name.

The purpose of this exercise is the next step in their transition from a group of people who merely work together to a real team that knows the value each team member brings. It also gives them an opportunity to think outside their technical box and talk about why they like what they do, how they got there and perhaps where they see themselves going. Essentially, it’s to further build the emotional connections within the team and with their coach or Scrum Master.

The exercise also provides some insights as to what motivates each team member and what may motivate the team. It is important to remember that motivation is done on a team level and on an individual level. I use the journey line information for each member as a guide for motivation and to aid them in the adoption of agile practices on an individual basis.

Sprint Planning

Sprint planning is where you show the team you’re serious about breaking away from the detrimental waterfall work patterns and empowering them to take ownership of the work. Using my sprint cycle as a reference, I limit team member capacity to 54 hours for project work per sprint. The limit is based on the concept of the ideal day being six hours.

The remaining time is used for backlog grooming sessions and a buffer to account for the fact that an estimate is not a certainty. I also allot four hours for sprint planning to allow them sufficient time to carefully plan. I want them to understand that sprint planning is all about planning for a sustainable pace and that the team as a whole is responsible for the success of the sprint. 

There is nothing more motivating for a team than completing all their stories in the sprint as a team and being able to do it consistently. The fact that they plan their work and then succeed reinforces not only teamwork, but also a sense of pride that can only be found in having ownership of the work.


The retrospective is not only about continuing improvement, it is also an opportunity to start empowering the team. In the confines of the safe and blame–free environment of the retrospective, I use the first two sprint retrospectives to give them the opportunity to tell me what went well and what didn’t go well.

I create three columns on the wall titled “Stop,” “Start” and “Keep.” Using sticky notes, I have everybody write one thought per sticky note and have them place each one in the appropriate column. Upon completion, the team then eliminates any duplicate notes. 

Moving forward I then open the discussion with the “Keep” list items to confirm with the team that these are practices we should keep doing. Next, we review the “Start” list and the “Stop” list items together to see if there is any correlation between the items in both lists. In other words, there may be a practice in the “Start” list that automatically eliminates a corresponding practice in the “Stop” list if we choose to implement that practice.

The important items will generally show up in both columns, confirming that they represent priority issues for the team. I then ask the team to select two items for action and come up with a quick plan to resolve them during the next sprint and report on progress in the next retrospective.

The purpose of this exercise is to show the team that when they have an issue, it is not only heard, but they can also take part in how it’s resolved. They are empowered to make their work environment better. The information gathered from these two retrospectives provides the basis for many improvements that can be taken on during future sprints, and frees up time in future retrospectives for exploration into other areas.

Another exercise, which I do during every retrospective, is the “note of appreciation.” I ask each team member to take one or two sticky notes and write down how another team member helped them out during the sprint. After everybody is finished, we go around the table and each team member reads their note aloud and hands it to that team member.

The purpose of the note of appreciation exercise is to show that while outside of the team, they will always be recognized by their team name for their successes, inside the team, we will always take time to recognize our teammates.


We continued our team building with a journey line exercise, using it to introduce the team members to each other. They learned about each other’s history and then acknowledged each person’s skills and the value that each brings to the team.

In doing so, we increased the individual comfort level that comes from being part of a team. We also talked about the importance of having a team identity to foster a sense of belonging.

We then moved to sprint planning where they were told the “what” and “why” that was needed and gave them the opportunity to determine “how” it was to be accomplished. We set reasonable boundaries by determining the team’s real capacity, thereby setting the stage for them to plan for success rather than putting them in a situation that was doomed to failure.

In doing so, we not only empowered them, but also gave an opportunity to take ownership of the work and an opportunity take pride in their success.

In the retrospective, we showed that it’s OK to fail (what didn’t go well) because we learn more from failures than we do from our successes, and when we resolve a failure, that success is all the sweeter.

They also learned that recognition comes in two forms:

Recognition for being part of a successful team Recognition for your work by people who really know your value

In the end, team building and motivation are all about people and how we regard one another. 

How to Build and Motivate Your Scrum Team: Part 1

“Understand their past so that you can better guide them toward their future.”

As an agile coach or Scrum Master, at one time or another, we have all faced the situation of introducing Scrum to a new team or turning around a Scrum team that has lost its way. I feel that the old saying about Scrum that “the concept is simple, it’s the execution that is hard” is referring to those two situations.

In either situation, the first thing you need to do is start from or go back to the beginning and treat these teams as if they were a new group of people.

You need to keep in mind that most core team members either come from:

A Waterfall environment where they were subjected to unrealistic deadlines, long work hours and their expert opinion ignored or never fully leveraged An agile environment that was agile in name only where the product owner and Scrum Master operated with Waterfall’s mentality, and the benefits that come from working on real a Scrum team were never realized.

Thus, calling a group of people a team, even if they have worked together before, does not necessarily make them a team. A team is composed of members that know through experience the value and the level of commitment that each team member brings to the team. This is something that does not happen overnight. It’s a journey that you and the team take together.

As an agile coach or Scrum Master, you need to connect with your team on a logical and emotional level. The logical level stems from your knowledge of Scrum and how well you transfer that knowledge to your team. The emotional level stems from the trust you build with the team and within the team as you guide them through the adoption of the Scrum framework and they come realize its benefits.

The First Step

The first step in the journey is level-setting the team through training. To make the logical connection, I want them to know what I know.

As part of my own continuing improvement, I’ve put together training slide decks for the Scrum Master, the product owner and the core team roles, which I use to ensure that they gain that all-important shared understanding of the Scrum roles and associated responsibilities.

I also find these training decks to be useful for bringing new members up to speed when changes occur within the team, and I continue to update them as I encounter new and better ways to express ideas.

The Second Step

The second step is to help them to decide what kind of team they really want to become and is where I lay the groundwork for building a team and starting to make the emotional connection. So, it is here that I ask them to tell me their thoughts on what makes a great team.

For this exercise, I have them write one thought per Post-It note and when finished, put them on the board. I often use Post-It notes to ensure full participation, especially from the less-vocal members in the group.

Once complete, we rack and stack the notes into three to five categories. Based on the number of categories, each member receives the same number of votes and is asked to go up to the board and select those thoughts on the board they feel are the most important characteristics of great team.

After the votes are tallied, we take the winning thoughts and turn them into value statements that are positive and mean same thing to everyone in the group.

The following is a sample of some actual team value statements:

Sharing knowledge and information freely and openly among team members. Putting the team first and the willingness to do any task necessary to reach each sprint goal. Asking for help when you need it and without delay, and helping others when they need help or when you find yourself with spare time. Taking the time to listen, understand and respect your teammates’ opinions and views.

I have been in many team spaces over the years where I’ve seen team values expressed using single words such as “responsibility,” “commitment,” “trust,” “respect,” etc. and find it sadly lacking because if I don’t know what the word “respect” means to the team, how can one expect those team members to know?

And if that is indeed the case, does this team really know what kind of team they really want to become?

However, when you look at the team value statements mentioned above, there is no question about what that team thinks it takes to be a great team. I would also like point out that value team statements are not a one-time exercise where you are done after you print it out and post it in the team’s space.

This is a tool you will use from time to time in your retrospectives where you might ask the team, “Did we as team live up to a specific team value during this sprint?” … or to remind them what kind of team they want to become. You might also add or adjust a team value statement as the result of what the team learned during a sprint.

The Third Step

The third step is to have this group of people come together to decide how they want to organize their workday. This is what I call a “team agreement,” an example of which is shown below.

Business Hours: 9:30 a.m. – 3:30 p.m. Daily Standup: 9:40 a.m. – 9:55 a.m. Coding Hours: 1 p.m. – 5 p.m. Mid-Sprint Check: Sprint Day 5

Business hours is the timeframe that the team agrees everyone should be on the premises. The daily standup time is when the team agrees to meet and plan their work for the day. Core hours are generally used for the team to engage with others. Coding hours is a period where the team is not to be disturbed so they can focus on work.

And, the mid-sprint check is the point in the sprint cycle where the team reviews the task board to determine if they are still on track to complete all the stories, and if not, how to adjust their work strategy to get back on track.


With this process, we take into consideration the group’s past project experience and focus on laying down a foundation for shaping this group of people into a team.

We start off making a logical connection by explaining the Scrum framework roles and responsibilities for every person in the group so that they now know what the job entails. We then engage them to tell us what they think makes a great team.

We ask them what is most important to each of them, and then assist them in creating their value statements, thereby making that first emotional connection. In the last step, we take our first opportunity to empower them by asking to self-organize their workday.

In Part 2 of this article, we will continue the journey and discuss how we further build on this foundation we laid out in Part 1 as we guide a team through the adoption of the Scrum framework. 

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.