“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 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.
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.
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.
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.
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.
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.
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.