by Jeffrey Ries
The Product Owner should then discuss the current state of the product backlog as well as the new delivery date for the final, final product based on the current progress. From there, the entire group should collaborate on what to do next so that the Sprint Review provides useful input for the next round of planning. This should also include a general review of the way in which the marketplace or target audience for the product might have changed during the last Sprint and if anything else needs to change as a response.
Finally, the entire team should review the new details surrounding the product as a whole as well as the current Increment and what the next Increment will look like assuming everything goes according to plan. Anything new is then added to the product backlog as needed.
Sprint retrospective: The Sprint Retrospective is the last opportunity for the team to check in with one another and ensure that there is a plan for enacting any changes that need to take place prior to the start of the next Sprint. Assuming your Sprint lasted one month, this meeting should last no longer than three hours. The Scrum Master should be in charge of keeping everyone on task for the meeting as well as ensuring that it stays within a reasonable timeframe. At the same time, however, the Scrum Master needs to participate as a peer in this meeting as well to ensure they feel the right level of accountability for the Scrum process as a whole.
The goal of the Sprint Retrospective is for the team to understand how effective the last Sprint was in regard to the tools used, processes streamlined, relationships formed and the people involved. This should include a look at what went well and what went poorly as well to ensure that when the team creates a plan for improvement with the next Sprint it accurately covers the scope of what needs to be done.
During this time the Scrum Master should do what they can to ensure the Scrum Team improves, while at the same time keeping everyone tied to the Scrum process framework with the end goal of making the process not only effective but also as enjoyable as work can be. For each Retrospective, the team should emerge with new ways of increasing product quality through an improvement to work process and possibly a change in what the definition of finished for the next Sprint will be. Assuming, of course, these changes don’t create a conflict between organizational or product standards.
By the end of each Retrospective, the entire team should have a clear idea of the improvements that will be implemented for the upcoming Sprint. Ensuring these improvements are implemented is where the adaptation part of the process comes into play. While various types of improvements should be implemented throughout the Sprint as they are discovered, the Sprint Retrospective represents an opportunity to focus on both adaptation and inspection in a more formal and focused context.
Chapter 4: Artifacts of Scrum
A Scrum artifact is anything that represents work or value to provide transparency and opportunities for inspection and adaptation. Scrum artifacts are all designed specifically to maximize the transparency of relevant information to ensure that everyone has the same understanding of every aspect of the current Sprint or Increment.
Product backlog: The Product Backlog serves as an ordered list of everything that will ultimately go into the product. This document will be the sole source of requirements for any future changes that will be made to the product. The Product Owner will be the one who is ultimately responsible for the backlog of the product, including things like ordering, determining availability and generating content.
Regardless of how much work is put into the product backlog at the start of the project, it is still going to be a living document which means it will never be truly complete. In fact, the earliest portion of its development is important as it makes it clear what the most clearly defined requirements as well as those that are most important when it comes to getting a working product up and running. The product backlog then evolves from there along with the uses it will have and the environments it will be used in.
The product backlog should ultimately include all the fixes, enhancements, requirements, functions and features that the product will eventually have in future releases. Items in the backlog should all have clearly defined attributes including things like value, estimate and order. These items also frequently include a type of test description designed to determine when it can be considered finished and fully integrated into the next Increment.
As a program starts to get regular use and gains value with users and the marketplace as a whole it generates additional feedback and, as a result, the Product Backlog becomes much more well-defined and extensive. These requirements never stop changing, which is part of the reason it is important for the backlog to be considered a living document.
It doesn’t matter how many different Scrum teams are working together on a product, they should all be working from the same product backlog. Refining the product backlog is the process of adding further detail and cost / benefit analysis estimates to existing product backlog items. This process requires the additional revision and review of the items that are already on the list and the Development Team is primarily in charge of determining when this process takes place. A good rule of thumb is that this should take up no more than 10 percent of the Development Team’s time. The Product Owner can also update the backlog and any of its items at any time at their discretion.
As a general rule, the higher that an item is on the product backlog, the more well defined it is. This, in turn, leads to more accurate estimates thanks to the increased clarity provided by all the additional details. Backlog items that are going to be dealt with next should be so refined that they can be easily fit into the time-box of the next Sprint because they are so well-defined which means they will be considered ready for selection when it comes time to plan the next Sprint.
In these instances, the Development team is responsible for all of the estimates, thought the Product Owner is not without a degree of sway as well. The Product Owner, in this case, will help by making it clear what trade-offs are available and answering any questions the Development Team might have.
Tracking progress: Throughout each Sprint, the total amount of work remaining should be able to be easily summed up. The Product Owner is responsible for tracking the amount of progress that has been made towards the end goal and updating this progress report after each Sprint Review. The Product Owner then compares the amount of work remaining at previous Sprint Reviews with the current review to ensure that everything is still proceeding apace. The resulting determinations should then be shared with the entire team.
There are many different practices when it comes to forecasting progress, including things like cumulative flows, burn-ups and burn-downs. None of this can ultimately replace the raw importance of pure empiricism, however, especially in complicated environments when the outcome is far from guaranteed.
Sprint backlog: The Sprint backlog is the product backlog for a specific Sprint as well as a place for delivering the requirements within the scope of the next Sprint. It can also be thought of as a forecast for the Development Team to all them to start considering what will need to be done in order to deliver the next Increment as effectively as possible.
The Sprint backlog is effective because it can make visible all of the work the Development Team considers necessary when it comes to meeting the current Sprint goal. To keep the continuous improvement rolling in, it should also include at least one major improvement as defined by the most recent Sprint Retrospective meeting. The Sprint backlog should contain enough details to make any changes that are made to it easily describable during the Daily Scrum.
When new work is required, the development team can add to the Sprint backlog directly. When the work is completed, the estimate for any remaining work should be updated as well. If specific elements of the plan are ultimately cut for one reason or another, they can then be easily removed. The Development Team is solely responsible for changing the Sprint backlog during the Sprint. As such, it serves as a real-time, extremely accurate, picture of the work the Te
am is currently working on and will finish by the time the Sprint is completed.
Tracking the progress of the Sprint: The total work that is left to do in the Sprint should be tracked in real time and summed up in a form that is easily accessible to anyone in the team. The Development Team should be in charge of tracking this work total, and updating it with each Daily Scrum to ensure the entire Scrum team knows the odds that the current goal is going to be achieved within the current Sprint.
Increment: The Increment can be thought of as the Product of all the added value the backlog items that have been completed during the Sprint have generated added to the value of all of the previous Sprints thus far. An increment can be thought of as a body of inspectable, completed work that supports the Sprint Goal as well as the end product goal that the Scrum Team is working towards.
Chapter 5: Scrum Master as Servant Leader
Responsibilities of a Servant-Leader
A ScrumMaster is a servant-leader in that it is their goal to facilitate the needs of all of the members of the team as well as anyone the team serves, which is typically the customer. They should strive to achieve results that line up with the goals of the Scrum Team as well as the larger organization’s business objectives, principles and values.
ScrumMaster responsibilities may include:
Setting up a Scrum framework in the service of the team, not as a way to command or micro-manage.
Giving the Development Team the tools they need to manage themselves successfully.
Mitigating conflict by ensuring that any disagreement is seen as a healthy exchange of ideas.
Ensuring that every member of the team is fully versed in the ins and outs of the Scrum framework.
Stepping in to handle anything that will get in the way of the Scrum Team reaching the goals of their current Sprint.
Doing anything that is required to remove any roadblocks that may come up during a Sprint.
Ensuring everyone on all sides of the team are being as transparent as possible.
Helping in any way possible that will lead to the team becoming better versions of themselves.
Nurturing a collaborative, supportive and empathic culture within the team.
Constantly keeping the team challenged and away from mediocrity.
Ensuring development, growth, and happiness of team members.
The Scrum Master is a servant-leader for the Scrum team. To encourage Servant Leadership behavior, the Scrum Master role by design does not have organizational authority or power. The Scrum Master is not a boss or an alternate title for a manager of the team.
The absence of organizational power, allows the Scrum Master to establish Psychological safety within the team. This, in turn, empowers the team members and allows them to self-organize. If the Scrum Master possesses organizational power, that limits the chances of establishing a safe environment.
A Servant-leader Scrum Master creates an environment where people can contribute and flourish. An environment where people are cared for and feel safe to express themselves. An environment where they've enough empowerment to make necessary decisions. Scrum Master is that leader for the Scrum team.
Who does the Scrum Master serve? The Scrum Master serves the Development Team, the Product Owner, and the Organization in their endeavor to apply Scrum and get benefits from it.
A Scrum Master enables the Scrum Team to become a high performing team. So much so, that it can rapidly adapt to the changing customer needs and solve customer challenges. For those Scrum Masters who also happens to have organizational authority - aka responsibility of product delivery, the team members reporting into you, you make financial decisions, you write performance reviews, etc. observe your behavior closely.
A good servant-leader Scrum Master should be able to answer the following questions:
If asked, will my colleagues and team members say that I serve them?
Whose agenda do I serve? Theirs or mine?
Am I able to justify the responsibility as a Servant-Leader Scrum Master?
How does Scrum Master's Servant-Leadership style work with traditional managers? The paradoxical style of Servant Leadership is difficult to enact for the traditional managers. Most managers tend to be comfortable with the leadership aspect, but not the servant aspect.
Servanthood and Caring: As a Scrum Master, you do not have any authority in the organization. You derive influence from your subject matter expertise of Scrum and by having the heart to serve your team and care for them.
As a Servant-Leader, you seek to empower the team members and invite them in decision making. Your behavior is of serving and caring. It enhances the growth of team members while improving the caring and quality of organizational life.
Is your emphasis on serving your team-members for their good and not just the good of the organization? If yes, then you sure are one effective Scrum Master.
Empowering and Helping: The Scrum Master needs to be concerned about what is going on with all of their stakeholders. Broadly stakeholders include society, communities, business partners and employees, and specifically the least privileged among them. Servant-Leader Scrum Masters believe that team members have an intrinsic value beyond their apparent responsibilities as employees. These Scrum Masters are deeply committed to the development and growth of each and every Scrum Team member. During their time spent as a Scrum Master, individuals need to learn to nurture the professional as well as the personal growth of team members.
Serving Team’s Agenda: A Scrum Master as a servant-leader uses his capabilities and skills to help the team establish their agenda. The Scrum Master serves the team's agenda, not their own.
The Scrum Master does not impose any directions or mandate upon the team. A Servant-leader Scrum Master instead, believes in Change by Invitation. They invite the team to choose the goals and the direction. They invite team members to opt into, participate and keep options open for anyone to opt out.
It is important to understand that if a person is titled as a Scrum Master but also carries the traditional manager's responsibility to deliver a release or to manage the team members etc. They'll not be able to truly serve the team's agenda. Such a person will almost always end up making others follow their direction and agenda that they set.
There is also a boundary to serving team's agenda. For example: if a product owner's agenda is to finish a certain number of features by this sprint, however, the team clearly sees that as not practical. Though you want the Product Owner to succeed, however, in such situation it is your responsibility to shield the Development Team from the excessive pressure of the Product Owner. Often Scrum Masters give-in to the pressure and allow the PO to overload the Dev Team.
What do you think is the result in situations when the Development Team was asked to deliver more than they could practically deliver?
a) A product having defects and poor quality
b) Stressed and overworked Team members from having to work extra nights and weekends
c) Accrual of Technical Debt
In any of the situation, can you say the Team's Agenda was served?
Building Relationships: Establishing and nurturing long-term relationships with all stakeholders and keeping the team-members in focus helps them meet their fullest potential. If you are genuinely serving, caring and helping your team members grow, building relations with them will not be an issue. To build longer term relations, you would need to forgo short term approach/gains and allow for the things to settle.
Healthy relations with the team create a synergy among the team-members and boosts the team's performance and growth. Is your emphasis on building long term and healthy relationships? If yes, you are on track.
Being Humble: Like a good leader, the Scrum Master stays humble and practices regular self-reflection. Counter to a traditional leader's pride, servant leaders exhibit humility in their behavior. Servant leaders don’t think less of themselves they just think of themselves less.
They have h
igh self-confidence but very low situational confidence. If they are faced with a situation, their response would most likely be: I have the intellect to solve all the problems, but I don’t have all the answers and for that, I need other people’s brain.
In today’s world where there are so much information and so many tools, it’s important to acknowledge that one person cannot know everything and that everyone needs or at some time will need his/her team members' help. A servant-leader will not take pride in the moments of success but will surely accept errors in times of failure.
Emotional Healing: Your people are going through change all the time. There is uncertainty and failures. Some of your people may have bruises. Many of them may go through emotional turbulences. Are you able to emotionally heal them? Offer your support?
As per the team development model, the team goes through Forming, Norming, Storming and Performing phases. While your team is going through Forming, Norming and Storming phase of the team development, as a Scrum Master, are standing by your team during this time of change? As a Servant-Leader, any emotional healing and support that you offer can go long way in building an environment of trust and care within the team.