Effective Scrum Master’s Dos and Don’ts

Scrum is a framework with just three roles (Product owner, Scrum master and Team), three artifacts (Product backlog, Sprint backlog and Burn-down chart) and a few ceremonies (Sprint planning, sprint review, sprint retrospective and daily stand up). Its easier to learn but way more difficult to practice. Adopting scrum is not just a change of titles but mindset. In this article I will focus on the role of a scrum master. Being only a good scrum master is not enough, effective is the goal. Below are the Dos and Don’ts for a scrum master to be effetive

Scrum Master Dos :

  1. Facilitate the product owner to maintain and prioritize the backlog items.
  2. Facilitate team members with any additional training or coaching required.
  3. Makes sure that team delivers the  true value to the business.
  4. Inspires the team members to own the tasks.
  5. Allow and help team members to make decisions.
  6. Removes any impediments holding the team back to achieve their goals.
  7. Helps team to become self-organised.
  8. Shields team from external interference.
  9. Acts as a servant leader.
  10. Should be willing to improve continuously.
  11. Handles only one team. If you  are a scrum master of more than one team, the commitment cannot be the same.

Scrum Master Don’ts :

  1. Own the decisions on product backlogs from product owner’s behalf.
  2. Make estimates on team’s behalf.
  3. Assign the tasks to the team members
  4. Try to manage the team.
  5. Make changes to team in middle of sprint.
  6. Accept backlog changes in middle of sprint.
  7. Make commitments on behalf of the team.

Scrum master does not control the team. He acts as a facilitator and works on the concept of servant leadership.

I hope this will help someone. Please add your thoughts in comments.


Understanding Agile Manifesto

In February 2001, seventeen software developers met at ski resort in Utah with the objective to find better ways to develop softwares. In their discussion they found consensus on four major values, now known as “Agile Manifesto”. All of us who practice agile, might have these values on our tips but its always good to periodically look at these values and check what they mean to us today.Agile Process

The four values of Agile Manifesto :

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

One good way to look into manifesto is, it defines preferences, not alternatives, encourages focus on particular area but does not eliminates others. It does not eliminate value in items on the right, it just encourages focus on the ones at left which can lead to a better software quality with high success rate. Lets discuss the each value in a bit of detail.

Individuals and interactions over process and tools : 

Softwares are built by team of people and to do that effectively they need to work together. As with the time processes and sophisticated tools were developed, focus shifted from individuals to tools and processes. Vendors are selling tools and processes as a solution. But all along it is still people who develops solutions. There is an old saying “A fool with a tool is still a fool”. So to me this point means  that the tools and processes should be minimum needed for a given situation. The focus should be more on individuals and interaction between them. For example QA team should not be isolated from dev team and similarly any other team committed to the delivery of product.

Working software over comprehensive documentation:

In a traditional waterfall model, customer is asked to explain the requirements and document it. Then the implementation team develop and test the software as per the documented requirements. Virtually its impossible for customer (infact anyone) to document the software they need. Even if it is, the requirements may change with the time and at the time of delivery customer might have different requirements as per the market at that time. The agile approach of building increments of ship-able product is very effective. At the end of every sprint customer can see the product and hence can come up with more idea or improvements he need for next sprint. This also builds the confidence of customer. But still there is some minimum documentation required. The question is, how much ? Agile says minimum documentation should be required for any software.

 Customer collaboration over contract negotiation:

Sometimes this statement is misunderstood as “we don’t need contracts and all collaboration is informal” which is not true. To me it means, our contracts should be flexible to accommodate the changes. Even with fixed price projects we can have flexible contracts. The changes can be discussed in sprint planning meeting and approvals can be taken for those.

Responding to change over following a plan:

Plans are made so complex and detailed that they are difficult to modify when change occurs. In agile process changes can be accommodated easily because it has simple artifacts like burndown charts. Progress can be tracked in agile process as well and its more transparent than waterfall model.


The whole Agile Manifesto is centered on delivering better software. Although waterfall model’s intentions were also the same, but it just didn’t happen. We focused on tools and processes so much that the real values were getting lost somewhere. Agile tries to fill that gap.

There are also examples where people have forgotten the values on right completely. This is also improper choice.

Remember, delivering a high quality software is still very hard.