Piyush Rahate

Often we are required to make predictions about the future, specially the cost and effort that would be required to complete a project/ set of features for a product. Now in a complex environment this is not easy as many variables are at play. But is there an approach or tool to guide us? The Cone of Uncertainty might help.

Is the role of Scrum Master really relevant when Scrum has become the norm while the Scrum Masters themselves have not really upskilled or reskilled to support the Scrum Teams.

Scrum Masters change styles and stances as needed. However, when someone who lacks knowledge or experience takes on this accountability, it often leads to Scrum Master anti-patterns. In this post I am sharing the anti-patterns and its pitfalls that I experienced, there could be more.

In this blog post from PST Piyush Rahate, he explores the reasons why Project Management can be a useful tool to the Product Owner and Scrum Master.

Product Owner is an accountability within Scrum. If you are not doing Scrum then there is no Product Owner. However, Scrum does not clarify besides a couple of bullet points what is expected of a Product Owner and it leaves a lot of grey area for people to interpret and mis-interpret the need of Product Owner.

One of the accountabilities that a Scrum Master has to fulfill is to make the Scrum Team effective. This includes the Scrum Master, as well. However, in my experience I have come across only a handful of Scrum Masters who understand the concept and who focus on improving and making themselves effective. If as a Scrum Master one does not focus on making themself effective they might not be able to help the team to become effective.

Story points could be a great tool when combined with planning poker for getting estimation related conversations started. However, there has been quite a backlash and debate on whether to use story points or not.

Every Sprint starts with a Sprint Planning event. It is very crucial to ensure that the Scrum Team comes to a shared understanding of what and how are they going to deliver a “Done” increment that creates maximum business impact. Although, like other events Sprint Planning also is often marred with few dysfunctions. In this post I will bring forth 5 common dysfunctions that I have observed associated with this event. Unavailable Product Owner: Product Owners often tend to think that their job is to pass on the requirements to the Development Team and that is good enough to get the work done. They spend too much time with the end-customers, stakeholders or just writing detailed requirements for the team. On the other hand they spend too little time with the team and are mostly unavailable to the team when they are needed the most. This leads to the most common dysfunction – unavailable Product Owner which percolates to other dysfunctions. Lack of Refinement: Since Product Owner is often unavailable, the development team skips the Product Backlog Refinement sessions. As we are aware, Product Backlog Refinement is a collaborative session where the Product Backlog Items are refined and moved towards the ready state i.e. detailed enough, ordered and estimated. Ordering of Product Backlog Items is accountability of the Product Owner, as well as providing enough details around any Product Backlog Item is job of the PO. Now, since the PO is not available then the refinement doesn’t add any value. Ambiguous Requirements: As enough time is not spent in Product Backlog Refinement, the development team sees the requirements for the first time during the Sprint Planning. Since, refinement has not happened these requirements are often vague and ambiguous. The development often does not have clue how to move forward. They spend lot of time going over and over a single PBI and thus not making use of the Sprint Planning event to Inspect and Adapt for the Sprint. Erroneous Forecasts: Since the team sees the PBIs for the first time during the Sprint Planning, they often do not have any clarity of how to approach the requirement, or they often overlook scenarios/complexities that may arise as they start implementing the requirements. As a result, the estimates provided by the team are either overestimated or underestimated. This in-turn leads to erroneous forecasts of what can be done during the Sprint or thereafter. No Shared Commitment : All the above four dysfunctions lead to the final dysfunction which is No Shared Commitment within the Scrum team. As the requirements are vague, the forecasts over/under estimated and there is no shared commitment within the Scrum Team, a tiff starts between the business (Product Owner) and delivery (the Development Team). A game of pointing fingers and highlighting what other has not done or could have done begins. None of which is conducive for the team to work as a cohesive unit. Conclusion: There might be many more dysfunctions that might lead to not having a successful Sprint Planning event. These are few that I came across. As a Scrum Master it is always good to be vigilant about such dysfunctions, reveal them and help the team to overcome the dysfunctions.

The Daily Scrum is an important Inspect and Adapt event for a Scrum team. Yet the purpose is often ignored and swept under the carpet by a multitude of teams.

As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect.