The Scrum Master as a Servant-Leader

Scrum Masters - If there is one aspect that can set an effective Scrum Master apart from the pack, it is Servant Leadership. Are you looking to be an effective Scrum Master?

In this in-depth guide I explore the Servant Leadership with the context of the Scrum Master role, the characteristics of a Servant-Leader and how you can apply these characteristics to become an effective Scrum Master.

A Servant-Leader desires to serve. A Servant-Leader serves first. This behaviour is opposite to a traditional manager’s style which is to Manage/Lead first.

A Scrum Master is a Servant-Leader. Scrum Master serves the Team’s agenda, helps them grow and succeed.

Jump to Topics Below:

What is Servant-Leadership | Servant Leadership and Scrum | Servant Leadership and Scrum Master Role | Experts on Servant-Leadership | 8 Servant-Leader Behaviours for Every Scrum Master

 

What is Servant-Leadership?

Servant Leadership is a philosophy and set of practices that are based on serving and caring for others, to lead. Servant Leadership behavior creates a more just and caring world by enriching people, and building better organizations.

Robert Greenleaf, defined a Servant-Leader as:

The Servant-Leader is servant first. It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That leader significantly differs from one who is leader first, may be due to the need to acquire power, material belonging, control and authority within the organization.

The leader-first and the servant-first are two extreme leadership styles. There are a variety of shades between these two styles.

Robert Greenleaf popularized the Servant Leadership movement in 1970 through his article – The Servant as Leader. In which he coined the words "Servant-Leader" and "Servant Leadership."

Servant Leadership and Scrum

How is Servant Leadership is useful for application of Scrum? Scrum is a team sport. Self-Organization and Team Collaboration is essential for the success of any Scrum implementation. This is practically not achievable in the presence of top-down, command-oriented management within organizations.

To enable self-organization teams must be free from central point of authority.

First, the 5 Scrum values - Openness, Respect, Commitment, Courage and Focus, align well with the philosophy of Servant Leadership.

It's about your character and behaviours. How you practice what you preach to your people. Do you respect your people, show openness while listening to their ideas, display courage in keeping their needs ahead of yours etc.

Second, the Scrum framework recognizes the role of the Scrum Master in making the Scrum successful. Scrum Guide clarifies that the Scrum Master is a Servant-Leader.

This is about people and serving them to help them be successful. As part of the Scrum Master’s role, the Scrum Guide lists the Scrum Master’s service to the Development Team, the Product Owner and the Organization. Scrum Master serves these roles to help them meet their goals and become successful.

Third, Scrum Master leads building a high performing team. Facilitates team's transformation.

It’s about the vision, the purpose, and the objectives. It’s about how Scrum Master leads the organization, to make progress towards a better future.

Servant Leadership and Scrum Master Role

The Scrum Master is a Servant-Leader for the Scrum Team – Scrum Guide. 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.

Absence of organizational power, allows the Scrum Master to establish Psychological safety within the team. Which in turn empowers the team members and allows them to self-organize.

A Scrum Master with her leadership, enables the Scrum Team to become High Performing Team that can rapidly adapt to the changing customer needs and solve customer challenges.

Who does the Scrum Master serve? The Scrum Master serves the Development Team, the Product Owner and the Organization in several ways in their endeavor to apply Scrum and get benefits from it.

A leader creates an environment where people can contribute and flourish. An environment where people are cared and feel safe to express themselves. An environment where they've enough empowernment to make necessary decisions. Scrum Master is that leader for the Scrum Team.

If the Scrum Master possesses organizational power, that limits the chances of establishing a safe environment.

How does Servant-Leadership style work with traditional managers? The paradoxical style of Servant Leadership is difficult to enact for the traditional managers. They are comfortable with the leadership aspect, but no the servant aspect.

If you are a Scrum Master who also happens to have organizational authority - aka responsibility of product delivery, the team members reporting in to you, you make financial decisions, you write performance reviews, etc. observe your behavior closely.

Ask yourself:

If asked, will my colleagues and team members say that I serve them?

Do I serve their agenda, or do they have to serve my agenda?

Am I able to justify responsibility as a Servant-Leader?

 

New Scrum Masters and Servant Leadership:

It's not uncommon for novice Scrum Masters to restrict themselves to being the servant or secretary of the Scrum Team.

First time and particularly untrained Scrum Master usually limit their focus on setting up the meeting invites, arranging supplies, jotting down the meeting minutes, updating team's tasks on the task board, creating reports and sending out communications on behalf of the team members or PO etc.

They mostly miss exhibiting the leadership aspect. It doesn't have to be this way.

What do experts say about Servant Leadership?

"The difference between Servant-Leaders and other leaders manifests in the care taken by the servant-first-leaders to ensure other people's needs are being served. A quick test of the servant leadership is:

a) Do those who are being served grow as persons?

b) Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?

c) What is the effect on the least privileged in society?

d) Will they benefit or at least not be further deprived?"

The servant leadership is not about being submissive, letting go or giving in. It is about the genuine interest to serve others.

Inspired by “Journey to the East” by Herman Hesse, Greenleaf coined the concept of the Servant-Leader. In “The Servant as Leader”, Greenleaf said:

...the Journey to the East story clearly says: the great leader is seen as servant first, and that simple fact is the key to her/his greatness. Leo - the character in the story, was actually the leader, all the time, but he was servant first because that was what he was, deep down within.

Leadership was bestowed upon a man who was a servant by nature. Leo was a servant first.

If there is a single characteristic of the servant-leader that stands out in Greenleaf's essay it is,

The desire to serve.

Another very insightful observation by Greenleaf is that Servant-Leaders are Self-Aware. "Awareness is not a giver of solace. It is just the opposite. It is a disturber and an awakener.

Able leaders are usually sharply awake and reasonably disturbed. They are not seekers after solace. They have their own inner serenity”.

From a Scrum Master's perspective, Servant Leadership is about identifying and serving the needs of the Team and the Stakeholders.

8 Servant-Leader Behaviours for every Scrum Master

 

The characteristics of Servant leadership are inherent to some people. These characteristics can be further learned and such behaviours can be refined through practice.

How to apply Servant Leadership in my role as a Scrum Master? If you want to become effective at the Scrum Master role, you may begin with asking: How can I develop Servant-Leadership skills? For Scrum Masters to display Servant-Leadership, it is essential to develop and practice Servant-Leader behaviors.

Below 8 Servant-Leader behaviours combined make them highly relevant for the Scrum Master role. Applied to any team and organisational environment, these Servant-Leadership behaviours transforms the organizational culture to a caring, safe and high-performing culture.

 

Let's take a look at these behaviours

#1 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 behaviour 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.

#2 Empowering and Helping:

Are you concerned about the success of all stakeholders? Broadly stakeholders include employees, customers, business partners, communities, and society, including  those who are the least privileged.

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 my work as a Scrum Master, I aimed to nurture the professional as well as personal growth of team members I worked with.

Let me share the story of Pat. Pat was one of our team members who had excellent business analysis and customer interview skills. Pat was going through some emotional challenges with his new wife. I invited him for a coffee one day. We briefly discussed his situation. I asked Pat, if he wanted my help? Pat showed interest and we setup time for three coaching sessions. We mutually agreed that the coaching will be intended to focus on how Pat can become aware of and possibly change his behaviour.

During our second session, I offered Pat to take a quick assessment to become aware of his own emotions. To understand the range of his emotions and what behaviour/situation, triggered the positive emotions and what triggered the negative emotion was first step.

Now Pat's aim was to identify the positive emotional triggers while he was with his wife and prolong those. Where as any triggers causing negative emotions and trauma were to be narrowed in duration and limited in intensity as much as possible. It wasn't easy or quick, however Pat was determined to change his situation.

Becoming aware of his emotions empowered him to identify how he can best deal with the circumstances. Pat would try to build up whenever he experienced positive emotions such as Joy, Hope, Pride, Inspiration, Awe, Gratitude, etc.

There are wide variety of opportunities where you can help your team members develop professional as well as personal capability and grow.

Think about what opportunities within your team exists this week where you can help your team members grow.

 

#3 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 her 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.

She invites the team to choose the goals and the direction. She invites team members to opt in to participate and keeps 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 traditional manager's responsibility to deliver a release, or to manage the team members etc, she'll not be able to truly serve the team's agenda. Such person will almost always end up making others follow her direction and agenda that she sets.

There is also a boundary to serving team's agenda. For example: If a Product Owner's agenda is to finish 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 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?

#4 Building Relationships:

Establishing and nurturing long-term relationships with all stakeholders, 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 creates a synergy among the team-members and boosts team's performance and growth.

Is your emphasis on building long term and healthy relationships? If yes, you are on track.

#5 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 behaviour.

Servant leaders don’t think less of themselves they just think of themselves less.

They have high 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 is so much information and so many tools, its 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.

 

#6 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 Tuckman’s Team Development development model, team go 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.

 

#7 Being Empathic:

Being Empathic involves deeply connecting with the emotions of the other individual without judgement and critique. It is an essential behaviour of Servant-Leaders. Empathy starts with listening. Genuinely being present in the moment with somebody and listening with your whole self helps understand the other person's situation. Here the aim is to slow down and listen with the intent to understand the meaning behind the words, meaning of what is being felt, and what is not being said. Empathy connects two people by heart. Connecting with someone by heart is much more powerful than connecting only through brain.

For Scrum Masters who are not naturally empathic (count me in with you), being aware of and caring about others' emotions is the starting point of developing empathy. Empathically listening to what your team members say and acknowledging what you sense+hear.

Such as:

Elena, you seem to worried. How can I help?

David, I hear you are concerned about Matt's behaviour. What would you like to happen?

When you lend someone your empathic ears, they get it. They feel safe and comfortable to share even more.

Scrum Master through Empathy builds relationships, heals the team members, earns trust and gains influence.

 

#8 Being Ethical:

The moral component of the Scrum Masters must be strong. Being ethical relates to the way in which a servant-leader makes choices, disciplines herself and chooses the right thing to do in the service of the team. The Scrum Master may also encourage the team to self reflect and establish high standards of moral and ethical behaviour.

The team members constantly observe the moral basis of the servant-leader's actions and organizational goals and relate to them. If you as a Scrum Master have ingrained integrity and professionalism in yourself, it'll be possible to bring it in the team.

Often times, the Scrum Master may realize that the team needs to mature and they must be empowered, educated to handle their own meetings, hold each other accountable, collaborate with users and PO and deliver value. And time comes when the Scrum Master may not be providing the best value for the team and hence should decide to either step down from that role or move on.

Displaying this high level of ethics and courage to step down from one's role, to let go, is the best way you can become really effective at performing the Scrum Master's role.

How to grow your leadership impact?

One of the essential aspects of being a leader is that you constantly reflect and adapt your leadership impact on the people you lead. Evaluate regularly if people you lead are impacted positively and are benefiting from your leadership? Your intention to serve the people you lead, empower your people and develop them is important, however, if your actions are not aligned their needs from you, your leadership impact is going to be severely limited. The best way to grow your leadership impact is to ask the people you lead.

 

Powerful Questions to upgrade your leadership impact

  • What is my team’s biggest challenge or pain point?
  • What can I do to make things better?

Everyone can potentially lead and everyone has the capability to play leadership role irrespective of the position they held in their organization.

Scrum Training

We offer public and corporate in-house, Certified ScrumMaster Training – CSM, Certified Scrum Product Owner Training – CSPO, and non-certification version of CSM and CSPO workshops. We offer corporate on-site workshops customized to your needs such as: Scrum for Teams, Experiential Scrum Master Workshop, Agile Boot-camp, Agile For Leaders, Agile Leadership, LeSS Framework Training, Facilitation and Agile Coaching Workshop, and Kanban Workshop.

Top 21 Scrum Master skills

Top 21 Scrum Master skills

ScrumMaster-skills-Agile For Growth

The use artificial intelligence in product development and corporations is growing significantly. With the help of AI we'll be able to automate many tasks - even the cognitive one's to certain extent. In this rapidly evolving market, having high performing and innovative teams will be a competitive advantage for any organization.

A Scrum Master who is able to help build high performing and innovative Scrum teams, and coach people can be a valuable asset for the organization.

While those Scrum Masters who only perform mundane tasks, write meeting minutes, create reports and enter data in the tool will see themselves get replaced by AI bots soon.

I think irrespective of the technological advancements there will still be a need of good Scrum Masters. An effective Scrum Master can help Scrum Team deliver results that are an order of magnitude better than mediocre Scrum Teams. The responsibilities of the Scrum Master may adjust with the time.

Great Scrum Masters will definitely contribute towards improving the business agility and helping organizational system as a whole.

Below I list top 18 Scrum Master skills in 2020.

I also invite you to contribute 3 top Scrum Master skills that should be part of this list.

 

Top Scrum Master Skills:

  1. Systems Thinking
  2. Adaptability
  3. People Skills - Positive Psychology, Social Psychology
  4. Complex Problem Solving
  5. Lean Thinking
  6. Agile Mindset, Growth Mindset
  7. Creativity
  8. Empathy
  9. Asking Questions
  10. Collaboration
  11. Facilitation
  12. Rapid Decision Making
  13. Negotiation
  14. Leading and Facilitating Change
  15. Focus
  16. Performing with Flow
  17. Motivation - Intrinsic Motivation
  18. Emotional Intelligence
  19. Which Skill should be listed?
  20. Which skill should be listed?
  21. Which skill should be listed?

I need your opinion to add 3 top Scrum Master skills that'll be valuable in 2020.

6 Benefits of Good User Stories

6 Benefits of Good User Stories

In previous two articles, we discussed:

Becoming user centric with User Stories and

How to write good User Stories

In this article, lets understand the fundamental benefits of good User Stories. I challenge teams that I coach to strive to realize all of these User Story benefits.

While you read the article, I encourage you to think: how can you get maximum value from applying User Stories? It could be a competitive advantage for your team!!

Don’t forget to take your User Story Benefits Assessment at the end of this article.

Benefits-of-Good-User-Stories

Without further ado, here are the

Good User Story Benefits: 

 

1. Highest Value Delivery:

This User Story Benefit is the mother of all benefits. Done well, User Stories help deliver highest value by focusing on small and immediate customer needs.

Traditional product development teams may spend months on a single function such as analysis, design, implementation etc, carrying a significant amount of work in progress without deliverying anything that is directly valuable to the customer immediately.

How could you take the old school requirements approach and turn it upside down?

Agile Teams break down user needs in to small features or tasks that can be implemented and delivered from few hours to few days. The ProductOwner actively prioritizes these user stories in terms of user value, risk and business value to significantly increase the value delivered by a team within first few sprints.

Delivery of highest value early in the product development allows the Product Owner to:

a) Start earning returns early.

b) Reduces the amount of investment that the organization needs put in – as the return from the product starts to pay for the new feature development at some point during the development.

c) Significantly increase the ROI.

 

2. Fosters Collaboration:

Good User Stories due to their minimalist characteristic, inharently give way to collaboration among the product development team, the Product Owner and the users of the product. While the traditional teams depend heavily on detailed documents and electronic tools, most AgileTeams collaborate with users to plan, implement and deliver customer value.

Minimal writing of the user’s needs encourage the team members to talk to the user(s) or the Product Owner when they are ready to implement a UserStory. These discussions allows room for diverse business-technical perspectives to come to light and gives way for creative and innovative ways of solving customer’s needs.

 

3. Brings User Closer:

By focusing on delivering highest customer value with each user story, the Agile teams are compelled to regularly connect with and collaborate with end users. Minimally written detail also encourages for the team members to talk to the user.

The team members directly connect with the user to understand the user’s perspective, challenges, pain points and opportunities that need to be addressed. The team members also get early feedback from users by demonstrating implemented User Stories as soon stories are DONE.

In case if you haven’t read yet, check out my article – Becoming User Centric with User Stories

 

4. Building Blocks of the Product:

With each customer value delivering User Story, the product is built incrementally. Building the product incrementally allows to rapidly adjust it to new direction. When sliced in smaller ideas to experiment, user stories allow for quick implementation and user feedback.

With each successfully implemented feature, the product gets shaped and the value of the product keeps increasing.

User Stories allow for easy addition and removal of features from the Product.

If the Product Owner decides to remove a non-performing feature from the product, it becomes easy to immediately toggle off a feature that was built as a small user story.

During development, when a user story acceptance criteria does not pass, the Product Owner can exclude that one story and still release rest of the features to production.

 

5. Boost Transparency:

Written collaboratively on index cards, User Stories increase transparency among with the team member, Product Owner and stakeholders. The index cards remain visible to everyone and allow for better collaboration and faster decision making.

Improved transparency also increases the Trust within the environment.

Order of User Stories create transparency about,

a) the priorities set by the Product Owner and

b) the customer segment / persona that is being addressed through a particular user story.

If any story has dependencies and is stuck, the impediment becomes immediately visible to all.

Transparency reduces a lot of waste from the process and improves team’s effectiveness.

It is not uncommon for teams transitioning from traditional software development practices to Scrum, to write user stories as long documents. The most effective tools – Index Cards and Sharpies are not meant for writing long documents. Prompting these teams to store (freeze) these long written stories in electronic document repository or a tool. Most of the tools are not designed to radiate information or improve transparency. Severely reducing the transparency of User Stories and related information.

Any practice that hampers the transparency effectively slows down a team and increases churn.

Improved Transparency is a serious advantage teams can get from user stories. Higher transparency could be a game changer for teams new to Scrum.

 

6. Shared Understanding:

How can better User Stories create shared understanding? Unlike the traditional approach where the business team writes requirements and hands over the documents to the development team to implement, the Agile approach is for the Product Owner and the Development team members to collaborate and collectively develop, refine, and split the user stories.

Working collaboratively improves the shared understanding of:

a) what is expected by (need of) the user and what is feasible from technology and business perspective.

b) what is intended by the Product Owner and what is understood / implemented by the development team.

 

7. Reduced Risk:

Bonus benefit number 7. There is one more important User Story benefit that is Reduced Risk.

Most traditional teams are not equipped with and lack proactive measures of reducing risk.

Effective User Stories by creating transparency, improving collaboration, creating shared understanding and orienting the teams to focus on customer needs, eliminates various potential risks such as – lack of communication risk, technical risk, financial risk, business risk, etc.

 

While getting all these user story benefits would be sexy, many teams have asked me questions such as:

  • Is getting these user story benefits realistic?
  • Do other teams get these benefits?
  • Does any team fully realize all these benefits?
  • What are usual challenges that prevent teams from getting all these benefits?

To help you explore your own answers, I’ve created User Story Benefits Assessment. In about a minute, you can self-assess and get instant scores.

 

Take the User Story Benefits Assessment now! Just scroll to the end of this page to take the assessment.

 

I just want to say, many times the appreciation of these User Story benefits come only when any risks arise from not having these benefits.

 

Actionable Tip: Let me invite you to identify and share in comments below – potentials risks for your product and team if these benefits of good user stories are missing.

 

Evaluate the User Story Benefits You Get Today!!

Evaluate and get your score now!!

The Scrum Master as a Servant-Leader

Scrum Masters - If there is one aspect that can set an effective Scrum Master apart from the pack, it is Servant Leadership. Are you looking to be...
Read More

How to grow your leadership impact?

One of the essential aspects of being a leader is that you constantly reflect and adapt your leadership impact on the people you lead. Evaluate...
Read More

Top 21 Scrum Master skills

The use artificial intelligence in product development and corporations is growing significantly. With the help of AI we'll be able to automate many...
Read More

6 Benefits of Good User Stories

Crafting good User Stories is rewarding. Understand the fundamental benefits of crafting good User Stories. Turn these user story benefits into your team’s competitive advantage. Take the assessment at the end of this article. Here are 6 User Story Benefits:
1- Highest Value Delivery
2- Fosters Collaboration
3- Brings User Closer
4- Building Blocks of the Product
5- Boost Transparency
6- Share Understanding

Read More

Essential Building Blocks of an Agile Organization

Creating cross-functional and self-organizing Teams is one of the essential element of building an Agile Organization.

Both aspects require significant effort & focus. These also don’t happen naturally, particularly in organizations led with Industrial Age style of organizational structure and management.

Scrum identifies these as essential aspects and recognizes a specific role – Scrum Master to be responsible for helping the teams and organization achieve Self Organization and improve cross-functionality.

In fact, Scrum Guide specifies it as the first aspect of the Scrum Master’s service towards the Development  Team.

The existence of organizational power and authority significantly limits the potential of self-organization, hence the Scrum Team is designed to not have any organizational authority and power by any of its members.

The Scrum Master doesn’t carry any authority and organizational power, as well as commits to serve the Team’s agenda. Any Scrum Master that doesn’t explicitly let go of authority and power, and does not commit to serving the team’s agenda, would counter to one of the primary purposes of the Scrum Master role. Such situation is not Scrum, as the organization won’t fully realize the intended benefits of implementing Scrum.

How to write Good User Stories?

storytelling user story

Why care for writing good User Stories?

Good User Stories are easy to understand and implement. Crafting valuable and small user stories could in most cases solve the biggest challenge of Scrum Teams – delivering shippable product increment every Sprint.

Mastering the art of crafting good user stories isn’t easy.

When crafted well, good User Stories form the building blocks of a successful product envisioned by the Product Owner and desired by the customer.

In traditional product development environment, the Product Owner / Business Team would write a requirement they want to be implemented and the team would simply implement it, to the extent they understand it. The User Story challenges this rationale. 

It requires identifying who (a user) exactly will use the feature being asked to develop and specifies what benefit the user will get. This helps remove ambiguity and offers clarity in understanding the User’s story.

As discussed in my article becoming user centric with User Stories – A User Story is a promise to further communication that should happen between the Product Owner and the team to create a shared understanding of the story of a user. A user story card may outline “why” – the benefit, “who” – the user and “what” – the feature or action.

A user story card may outline “why” – the benefit, “who” – the user and “what” – the feature or action.

What makes a good User Story?

In order to understand what makes a good User Story, it is important to understand what the User story means for everyone involved in creating and implementing it.

Product Owner: For the Product Owner, User Stories are a way of putting user’s needs, wish list items, hypothesis and everything else required of the product on a set of cards. The Product Owner collaborates with the development team to refine user stories. The PO orders these user story cards in order of the customer value, business priorities and risk for the development team to work on. User Stories also help the PO initiates the conversations with the Development team to create shared understanding about why, what needs to be implemented, who will benefit from it and how.

Development Team: User Stories open avenues for the Development team to get closer to the user’s need, who will benefit from it and formulate how they would implement it to achieve the desired outcome. User stories also help with tracking the progress of the development within a sprint and create transparency within the Scrum Team. It helps plan the sprint.

Scrum Master: The Scrum Master ensures that the User Stories are transparent and that the team members and the Product Owner have a shared understanding of the User stories. If the Product Owner and the development team are bound in written contracts called requirements documents or the User Stories and are not collaborating, the ScrumMaster can facilitate communication and collaboration. Scrum Master would take responsibility to help everyone understand the importance of keeping the user stories small, being flexible and allow for the most relevant user needs to emerge while discovery and development.

Most novice ScrumMasters end up doing just the opposite. They start helping the Scrum Team to write detailed user stories (kind of mini requirements documents), police around to ensure the electronic tool is filled with all 16 types of user story fields, detailed descriptions are written and every possible acceptance criteria are listed.

Writing detailed user stories is 1st step to stifle collaboration within the Scrum Team.

Traditional mindset, lack of trust in the work environment, geographical distance between the PO and the DevTeam, and client-vendor setup, all such factors encourage writing detailed requirements.

The Scrum Master should be able to pick up early smells and help the Scrum Team avoid falling into such trap.

User Stories encourages the Product Owner and the development team to collaborate with the User and to stay close to what the User needs. Scrum encourages collaboration by face-to-face communication. This makes User Stories a logical fit (as a practice) with the Scrum framework.

A simple User Story template, widely used by Scrum practitioners involves these three elements:

As a <<USER>>,

I want <<FEATURE>>,

So that <<VALUE>>.

This simple template narrates the value for the User. The primary focus of the User Story written using this template should be the Business Value that the Product Owner is trying to achieve by having the User Story implemented.

How to write a good User Story?

 

Here are three characteristics that help craft a good User Story.

1. Identify the Business Value:

To make a product successful, the Product Owner tries to maximize the business value being delivered by the User Story. In order to maximize the business value, its important to first identify whats the Business Value that the team is trying to achieve by implementing a User Story and all the effort that goes around it. Understanding the Business value also helps the Product Owner to prioritize User Stories and have the User Stories with the highest Business Value at the top of the Product Backlog.

Example: For a new e-commerce website to launch, the highest Business Value will be when a new user is able to buy an item from the website. Let’s take a closer look. Traditionally, the line of thought for the sequential functionality being made available would have been in the below sequence:

1a. New user can register on the website

User Story Example 1:

As a First time visitor to the website,

   I want to be able to register on the website,

   So that I can browse and buy listed products from the website.

 

1b. Registered User can Browse items listed

User Story Example 2:

   As a Registered Website User,

   I want to be able to browse listed products from the website,

   So that I can make my choice and buy a listed product from the website.

 

1c. Registered User can add items to the cart

User Story Example 3:

   As a Registered Website User,

   I want to be able to add items to the cart,

   So that I can buy a listed product from the website.

 

1d. Registered User can make payment for the items added to the cart.

User Story Example 4:

   As a Registered Website User,

   I want to be able to buy listed products,

   So that I can use the product I buy.

 

Looking closely at the User Stories above tells us that the website visitor would not be able to make a purchase on the e-commerce website till the time User Story 4 is implemented and made available at the website.

The Human brain thinks sequentially, step-by-step and the above User Stories are evidence that the Product Owner writing the above user stories is looking at the website from the perspective of the end user and trying to depict his/her sequential line of thought.

Now if you wear the hat of a Product Owner, you must think about how can the highest Business Value be delivered early?

That requires prioritizing user stories in a way that the highest Business Value User Story finds its place at the top of the Product Backlog.

If you thinking out of the box and not sequentially as the human brain is trained to think, here is an alternate option to craft the User Story:

User Story Example 5:

   As a First-time visitor to the e-commerce website,

   I want to be able to buy listed product,

   So that I can use the product I buy.

 

This means that the First-time visitor to the e-commerce website should be able to make the payment as a guest user without having to register – User Story Example 1.

Does buying the product has more value than Browsing products – User Story Example 2? Sure, any day.

Adding chosen products to the cart – User Story Example 3 is a nice to have and allows the user to buy multiple items at the same time. However, being able to buy the product – User Story Example 5 without registering, browsing or adding the products to the cart has the highest Business Value.

2. Identify the “who”:

It’s important and imperative to identify the Customer being served before you craft a User Story. One of the most common mistakes done by novice Scrum Teams is to generalize the User segment being served by a User Story.

Identifying a narrow and specific User segment being served by the User Story, helps reduce the size of the User Story.

The User Story becomes specific and clear as to who is being targeted. Many Scrum teams use User Personas for their product and specify a particular persona for each user story.

Example: I had once worked on a capability that was available for all Credit Card users on the desktop. Our team was developing the set of features to make the capability available on an App for Tablet and Mobile users.

The team started with this format:

   As an App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

Now we had an option to split as a “Mobile App User” and “Tablet App User”. The Product Owner prioritized the “Mobile App User” over the “Tablet App User” since that User Segment had higher volume and more business value. So, the PO chose to go with:

   As a Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>

Then, we had an option to split the user story as an “Andriod Mobile App user” or “iOS Mobile App user”. The Product Owner prioritized the “iOS Mobile App user” over the “Android Mobile App user” since that was a User Segment with even more business value. So, we chose to go with:

   As an iOS Mobile App user,

   I want <<FEATURE>>,

   So that <<VALUE>>.

In addition to this, we had Silver, Gold and Platinum Credit Card, holders. The Product Owner prioritized the “Platinum Credit Card holder” since that was a User Segment with highest business value. Our user story looked like:

   As an iOS Mobile App user holding a Platinum Credit Card,

   I want <<FEATURE>>,

   So that <<VALUE>>.

This is the level where the Scrum team was clear as to who was served by implementing the User Story.

Identifying a very specific user segment provides clarity, creates shared understanding, reduces risk and results in improved ROI for the efforts.

 

3. Understand the “what”:

Communicating clearly “what” will be delivered as a part of the User Story is crucial too. This is the part of the User Story where the customer has an avenue to communicate his/her perspective of what s/he needs – feature, enhancement, etc.

Example: In another implementation that I had a chance to work on, we were implementing the approval system of a large Custodian bank. Can you believe they were dealing with Billions of Dollars yet the process was pretty much manual?

Anyways, using this Business Process Management tool, various departments involved would review and approve the application from a Sub-custodian bank to become a registered Sub-custodian to the Custodian based in the United States. The end goal was to create an automated system where:

  1. The interested Sub-custodian would apply online with all the details and documentation required by the Custodian, once that is done
  2. The Custodian would do multiple levels of review within the departments that existed in the Custodian bank.
  3. The application would then be sent to the regulatory body for their approval.
  4. Once approved by the regulatory body, the Custodian Bank would revert to the Sub-custodian requesting additional documentation required to formalize and close the registration process with the Custodian Bank.

As it appears, this was a huge task by itself. The team decided to break it down into bite-sized features. Although the team was going to use an off the shelf product with most of the functionalities required, yet there was a lot of customization required at each step.

With the array of features required to be implemented, we chose to first target the internal audience with the Custodian bank and the various departments within the bank whose approval was required as part of the registration process. We narrowed down the User to one department within the whole approval flow. We then decided to drop off the option of being able to attach the documents to the approval flow. Now the User Stories looked like:

   As a Registration team member,

   I want to be able to review the Sub-custodian application,

   So that <<VALUE>>.

 

   As a Registration team member,

   I want to be able to approve the Sub-custodian application,

   So that <<VALUE>>.

 

   As a Registration team member,

   I want to be able to reject the Sub-custodian application,

   So that <<VALUE>>.

 

These were easier to understand and also gave the Scrum Team a perspective into what’s being sought. Each User Story was crafted in a way that it could be implemented within a Sprint. Breaking it down to the specifics removed ambiguity.

In summary, nailing the “who”, “what” and “why” of the User Stories, making them transparent, valuable and small makes them viable survivable experiments for the Scrum team. It allows the Scrum Team to learn fast and inspect and adapt, resulting in reduced risk and better alignment with customer needs.

 

Do you have a story to share that your team crafted well and delighted the customer?

Agile Assessment – Check How Agile is your Team? Fast!!

Agile Assessment – Check How Agile is your Team? Fast!!

Agile Team Assessment by Agile For Growth

At one point during agile transformation, you may look at your practices, your team, and the organization and may want to assess the Agility of your team and the Organization. Taking the Agile Assessment may help you explore –

> How Agile are we?

> Are we really Agile?

> Are we doing it right? etc.

Well, the benefits you reap from Agile Transformation should actually give you the indication of how Agile you are. What are the typical benefits you should see if your teams have improved their agility?

What are the typical benefits you should see if your teams have become Agile and improved their agility?

  • Improved ability to respond to changing customer needs
  • Reduced time from idea to experimentation to products/features that customers can use
  • Improved alignment of your products with your customer’s needs resulting in growth opportunities for your business
  • Better alignment within the organization. For example Among marketing-product-delivery teams.
  • Significant reduction of waste from processes
  • Boost in Employee Engagement and Morale

It is realistic that while transitioning from traditional product development to Agile development, teams, and organizations improve at a linear pace in most cases. Their performance improves in few areas but remains lackluster in others.

It is important that the team members are aware of their strengths and the areas that need improvement. To help teams with such evaluation, there are a plethora of commercial Agile assessments available in the market. Most commercial surveys and assessments focus on the frameworks, processes and practices aspects leading the teams in the opposite direction to where the teams should focus on.

While creating the Agile Assessment, my primary focus was to help you to shed all the layers of the processes and practices and go back to the core of being Agile.

Agile Assessment assess your team agility with respect to proven areas such as:

Principles behind the Agile Manifesto

Human Psychology and Motivation

Keys to Successful Google Teams

I’ve tried to make the entire assessment as simple as possible. On top of that, you get Instant scores – sent to your email id. No waiting. Don’t get fooled by the simplicity of this powerful assessment. Give it a try now!

After the Agile Assessment

After you take the Agile Assessment, you’ll instantly get an email from me with your scores. Watch out for my email. Just in case if you don’t find it in your inbox, look for other folders – Promotions, Updates, Spam – depends on your email provider. Add my email id to your contacts.

Based on your scores, I also help you to understand your scores and the potential organizational factors responsible for your scores. I share relevant pointers and ideas to try within your team to improve your scores.

Follow up

To get best results and growth, I encourage you to take this assessment again after one month and compare your scores.

It’ll take less than 10 minutes to take the Agile Assessment. Give it a try now!

Becoming User centric with User Stories

Becoming User centric with User Stories

storytelling user story

Traditional product development creates functional barriers that separate the product developers from the users of the product. The reason user stories were used in the Extreme Programming was to connect the product developers with the real-world stories of the customers and users. Stories help the developers understand the pain areas of the users and the opportunities of delighting the users and making them feel awesome.

Today, for most of the teams, User Stories have just become a form in an electronic tool which someone should fill in so that it can enter the Sprint planning, get developed and shipped. Instead of learning the art of storytelling, Product Owners and Teams are often found searching for the perfect ways to fill the User Story templates . In this process, the real intent of the user stories is somewhat lost.

To benefit from the User Stories, teams must go back to the original intent of connecting with the users and learning the user’s latent pain and gain areas, understand their emotions and how a product can help make users’ life easy.

Medtronic, a Minnesota-based medical technology company has institutionalized the art of this storytelling. Every year at the annual employee gathering Medtronic brings in users to share their life transforming stories with all the employees. Leaders at Medtronic use every opportunity to share User’s Stories in their messages. They use both positive and negative stories to reinforce to employees its guiding principle of “Customers First”.

User Stories help product developers understand the impact they have on the people they serve. Understanding the story of the users also empower the developers to find the best way of solving a challenge.

User Stories act as a bridge between users and product developers.

User Stories are most popularly used today in the Agile software development field particularly with the Scrum Framework.

Often index cards are used to write User stories that focus on the benefit to the user. It consists of one or more sentences in the everyday language or the language of the end user (user perspective) that captures description of the story and benefit to the user. It also captures criteria for its acceptance. It helps in shifting the focus from writing about requirements to discussing about the benefits to user(s).

User story card captures the ‘why’, ‘who’ and ‘what’ of a potential feature or hypothesis in simple and concise way. Often limited to detail which can be hand-written on an Index card.

When used with Scrum Framework, a user story should essentially will be small enough so it can be delivered within one sprint and valuable enough so that a user can use it and provide her feedback.

INVEST

Bill Wake came up with INVEST acronym to emphasize what makes up a good User Story:

 

 

INVEST

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Independent

User stories are easiest to work with if they are independent i.e. it shouldn’t overlap in the concept. The team may creatively break the technical dependencies as often as possible to create independent stories.

Negotiable

A good user-story should be negotiable. It should capture the essence of the requirement and not the detail hence allowing the team and the Product Owner to negotiate the scope and approach of developing it.

Valuable

A good user-story needs to be valuable to the customer. It should clearly answer the “why” so the resulting product increment becomes valuable for the user an essential condition for a user to be able to use the product and share feedback. This criterion also draws attention to avoid creating stories that does not deliver customer value such as – story that only focuses on single function such as database work, or platform enhancement or only UI tasks.

Estimable

A team should understand the story well enough to be able to estimate how much time, effort will be required to deliver a testable and acceptable feature. The estimates allow the Product Owner to forecast the budget and delivery timeline.

Small

A good story typically represents at most a couple of person-days’ worth of work. If the work exceeds a week, the team may have difficulty in delivering a user story hence running into the risk of not delivering it within a sprint. Delay in delivering the user story delays the feedback again increasing the associated risk of failure.

Testable

A good user story is testable, i.e. everyone should well understand how the completion of the story will be verified by a user or a proxy of the user that is a Product Owner. It should be understood well enough so that tests can be written and performed. Acceptance Criteria helps establish this user acceptance testing. In case if a story can’t be tested, its scope should be reframed in a way so it can be tested.

Creation of user-story

Once I was coaching a team that was transitioning from traditional product development to implement Scrum. It was their first day after I facilitated a 3 day Agile Team Boot camp for their entire team. Their Product Owner – Jane was excited to get started with user stories and creating their first product backlog. They did have the knowledge that it’s going to be different from their usual approach of writing long multi-page requirements documents. The knowledge had to be put in to practice. Jane and the team members had to cautiously put in efforts to get away from their way of thinking and behaviour of writing long requirements documents and dumping those to their shared document repository and hope that everyone on the team will read, understand and deliver product as intended. That was never the case.

At the beginning of the working session, we did a 2-minute activity to recall points they learned about the User Stories during the boot camp. During this activity, Sri one of the team members stood up and recalled:

A User Story card is a promise for a conversation

Not a mini requirements document, not a requirement itself, a user story card is a promise by the Product Owner for a conversation with the team members when the team picks up a story for implementation. Alistair Cockburn, shares how it was done by the Chrysler C3 team in 1998 when it was first used:

A programmer would pick up a story card, walk over the Customer, and say, “Tell me about this”, then go over and program it up, and come back again and ask, “Like this?”, and back and forth until it was done. The ‘requirements’ were never written down, they communicated in discussion and feedback.

Not writing down requirements felt uncomfortable for Jane in the beginning. Jane and the team members collectively formulated and wrote (new) user-stories. Stakeholders were invited to contribute to writing user stories based on their needs. During the workshop, the intent was to write down high level 1-2 line description of each user need, feature, and hypothesis. There were lot of queries and as we navigated through the workshop, each query was discussed, explored and addressed.

Below I list some of the common User Story queries that I’ve heard.

One of the common way teams write user stories is in the form of:

As a <user type>, I want to <some goal>, so that <benefit>

A crisp user story should answer the following three questions:

  • As a <type of user>: Who are we building it for, who the user is?
  • I want to <action>: What action the user should be able to perform, what is the intention?
  • so that <benefit>: Why are we building it or what value it brings to the user?

 

Three common user story errors to avoid

  1. Missing User: If a story doesn’t specify the user, it is most likely going to miss the user’s story. If there is no user and no story the result is far from being a User Story. As simple and silly as it sounds, this is one of the most common error teams make. You may see it in the stories that say something like – As a DBA, I want to….., As a System Admin, I want to….., etc. It takes cautious effort on part of the Product Owner to pro-actively connect with users, listen to their stories and bring them to the team. Each user story may specifically address one user or a group of users with similar needs. Get this one right and you are on the track.

 

  1. Too much detail: This one is again resulting from the old mindset of writing down detailed requirements. The Product Owner tries to write every detail in the user-story forgetting the fact that a user story is a promise for a conversation not the requirement itself. Too much detail often dilutes the purpose of the User-story and hinders the team members from having the conversation with the product owner. Writing down too much detail in the user story can conveniently hide the fact that users’ input, users’ story has not been considered before formulating the user story. Necessity to write down too much detail may also be an indication of lack of sufficient trust in the environment – often prevailing in the cases where the Product Owner and the team members work from different geographies.

 

  1. Answers ‘how’ and misses ‘what’: A user-story should define what the product should do and what benefit should it yield not the specific approach of how it is achieved. The approach to achieve a user story’s intended outcome should be left for the development team to identify. After the high-level task of writing user stories was completed, the next task was refinement. To refine user stories, split larger stories, add description, write acceptance criteria etc. The team invited the Scrum Master to setup a follow up session to refine the user stories.

 

Who can become a Scrum Master?

Who can become a Scrum Master?

Who can become a Scrum Master?

Is there any particular background required to become a successful ScrumMaster?

Hi This is Kamlesh Ravlani, Scrum Trainer and Agile Coach with Agile For Growth. I am an Engineer by heart, and for many years I've worked as an Engineer, Team Lead, Project/Program Manager and Program Director before I moved to become a full-time Scrum Master.

In this video, I discuss:

> Is there any particular background required to become an effective ScrumMaster,

> I share with you the 10 most common backgrounds of ScrumMaster I've worked with, and

> I also give you a 5 point checklist to become successful in the ScrumMaster role.

The good news is, you don't need a specific background to become a Scrum Master. People having the skillset of Scrum Master can come from any field.

and, the not-so-good news is, it's hard and takes years of skillful practice to become an effective Scrum Master.

So before discussing who can become an effective ScrumMaster, let's understand the key skills required to perform ScrumMaster role, which are:

  • Facilitation
  • Teaching &
  • Coaching

Can you develop these skills? Why not!!

These skills help you to leverage your existing background in helping the teams you serve.

Now, let me share with you the 10 most common backgrounds I've seen good Scrum Master have come from:

10 most common backgrounds

  1. Program Manager, Project Manager
  2. Program Director, Director of Delivery
  3. CTO, CIO
  4. Product Manager
  5. Business Analyst
  6. QA Lead, Test Manager
  7. Technical Lead/ Developer
  8. DBA
  9. Customer Support Lead
  10. Release and Operations Lead

 

become-scrum-master-infographic

Are you one of them?. It doesn't matter if you are not.

You can still become an effective Scrum Master by following this 5 point checklist

5 point Checklist to become an Effective Scrum Master

  1. Are you adept at influencing people?
  2. Are you passionate to delight customers?
  3. Are you driven by the motive of serving your team?
  4. Do you have experience in the domain or the product that your teams are working on?
  5. Do you understand Scrum well?

 

Effective Scrum Master Checklist Infographic

Are you one of them?

It doesn't matter if you are not!

Depending on what background you come from, you may need to acquire new skills of Scrum Master role and you may also need to unlearn some bad behaviors that may hinder you from performing the Scrum Master's role effectively.

Such as- If you manage Finance, If you Write performance appraisals, If the Scrum team members report to you, you may have to explicitly let go of that organizational power and authority to be able to serve the team as Scrum Master.

Please tell me in comments, your thoughts, and experiences about who can become an effective Scrum Master?

7 Tips for Writing Acceptance Criteria with Examples

7 Tips for Writing Acceptance Criteria with Examples

Acceptance Criteria

Acceptance Criteria Definition: Acceptance Criteria defines from an end user’s perspective, how a particular feature could be used. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing which establishes the conditions of success of the feature.

Acceptance criteria could establish boundary that helps to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behaviour in happy path scenarios, it also guides the user experience in the case if something doesn’t work as intended. It describes what would be verified by the acceptance tests.

When the product owner verifies particular user story acceptance criteria and the developed feature passes the it, the development of the user story is considered a success. Pass / fail type results allow AC to form the basis of creating tests that can be automated and executed.

Tips for writing Acceptance Criteria

An essential aspect of writing good user story involves writing good acceptance criteria. It is the key to effectively testing the developed functionality. It allows the acceptance-criteria-tips-agile-for-growthteam members writing acceptance tests to understand the scope of the user story or Product Backlog Item (PBI).

How to define acceptance criteria? Here are some useful tips for writing AC for user stories. Some of the Scrum teams I’ve worked with preferred to use these ac tips as a checklist for writing good acceptance criteria. Acceptance criteria checklist helped with consistency and acted as training wheels for new team members. I encourage the teams to keep revisiting and revising these tips to fit their need. I would also forewarn to avoid using these tips as fixed rules.

7 Tips to write Acceptance-Criteria

Here are 7 tips for writing acceptance criteria:

  1. Each product backlog item or user story should have at least one acceptance criteria. Hey don’t take writing acceptance criteria lightly or think of skipping it.
  2. Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams. Write acceptance criteria after the implementation and miss the benefits.
  3. Each acceptance criterion is independently testable. Why shouldn’t it be?
  4. Acceptance critera has a clear Pass / Fail result. Write complex and long sentences at your own risk.
  5. It focuses on the end result – What. Not the solution approach – How.
  6. Include functional as well as non-functional criteria.
  7. Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared-understanding of the user story.

 

Who writes acceptance criteria?

Acceptance criteria are usually developed jointly by the development team and the product owner. Who writes the acceptance criteria, or who defines the acceptance criteria is not a matter of rules or convenience.

What matters is – writing acceptance criteria (AC) should help establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building the product capability.

One practice your can try avoiding is where the Product Owner writes all the AC. Why so?

When you encourage the team members write the AC, they must first understand the intended purpose of the feature and the outcome it must generate for the users.

Writing AC clarifies the scope for the team and also allows for the Product Owner to verify if the team and the PO have a shared understanding of the feature.

Acceptance Criteria examples

Product Backlog Item (User Story) example

acceptance criteria example for Pay Balance Due PBI

Example 1: User story and it’s acceptance criteria:

As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.

the acceptance criteria for this story could be:

  • Display statement balance upon authentication. Say for example $1560
  • Display total balance. For example $3560. Here the balance due from the current period is $2560 and past balance due is $2000.
  • Show Minimum payment due. For example $140
  • Show Payment due date. For example May 16th of the current month
  • Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again.’
User Story example 2

acceptance criteria example for student performance PBI

Example 2: User story and it’s acceptance criteria:

As a teacher, I want to generate assessment report, so I can evaluate student performance.

the acceptance criteria for this story could be:

  • Show a student’s current assessment score.
  • Display past assessment score of the student.
  • Provide an option to Print / Save / Share. (By the way, this could be split as a separate user story by itself).
  • Display error message if service not responding. (If a team chooses to add the Error Message as their definition of done for all stories – where ever applicable, it could be omitted from the acceptance criteria).

What is the right amount of Acceptance Criteria?

Well, if you’ve too many AC for a single product backlog item (PBI), chances are you could split it into multiple PBIs.

Tip: Have too many criteria as part of one story and chances are you’ll easily run into at least one criteria that isn’t passing.

That delays the delivery of that user story, which delays the feedback, ultimately increasing the risk of failure. I recommend, whenever you have got a chance, please go ahead and split the user story right there. You can thank me later 🙂

acceptance criteria detail for user stories

Splitting user stories helps in keeping each user story small, improves chances of delivering it early, seeking feedback faster, hence reduces risk. Yes, there is effort involved in splitting the user stories as well.

Hence, the PO and the development team have to identify for each user story, what is a barely sufficient detail of AC. Photo source: Kenny Rubin, Innolution where Ken discusses the pros and cons of adding too many details versus no detail and establishes the need to identify what is barely sufficient detail to get started.

It’s important that your team members spend a little time and get good at writing acceptance criteria. It’s benefits are long lasting and ROI of the effort is simply too high to ignore.

Rule of Thumb: My rule of thumb for number of acceptance criteria is to have between 1-3 per user story. If a user story have between 4-5 of these, I start exploring options to split the story. If there are 6 or more criterion then the chances are the team won’t be able to implement it all in one sprint, definitely this story needs to be split in more than one.

Remember small user stories with lesser scope can be delivered comfortable within a sprint and presented to users for feedback. Early feedback reduces risk and impact of failure.

 

When to write Acceptance Criteria?

Acceptance criteria (AC) should be written anytime before the user story is deemed ready to enter the Sprint Planning. Usually it is written during the product backlog refinement meeting. AC can be progressively developed and added to a user story during the refinement. However it should not be kept for when the development team start implementing a user story.

“If we write and review the acceptance critera before implementation begins, we’re more likely to capture the customer intent rather than the development reality” writes Steve Povilaitis.

To ensure the AC is defined for each user story upfront, many teams add writing acceptance criteria for User Stories to their User Story Readiness Checklist. User Stories that do not have at least one AC can’t enter the Sprint Planning itself. Well, that shouldn’t prevent the team from exploring the intent or refining the AC after the Sprint Planning / before the implementation when the team members have conversations with the Product Owner.

What you should do now

1. If you’d like us to work with your teams — to dramatically improve your product management, product development, organizational agility, and growth (like we did for many clients from fortune 500s to young startups), then leave your inquiry and claim a free Agile Coaching strategy session. On this free phone consultation, one of our expert coaches will discuss your agility goals and suggest strategies to improve your team and organizational agility.

2. If you’d like to assess your team agility for free, go to our Agile Assessment, where you can instantly evaluate the current agility of your team and identify the gap between their current state and desired state. Or, if you’d like us to build your company’s in-house capabilities to be Agile (not for free), then contact us and we’ll discuss your requirements.

3. If you’d like to read further —  see our recent insightful Scrum articles

4. If you enjoyed this article, so will your friends. Why not share it on LinkedInTwitterFacebook and Email

Subscribe To Our Newsletter

Join our mailing list to receive the latest news and updates from our team.

Awesome. You've successfully subscribed.