Do Scrum, and Do It Fully!

“…Careful alignment, unity of purpose and clarity of goal come together, it’s the perfect metaphor for what I want teams to do.” — Jeff Sutherland in Scrum: The Art of Doing Twice the Work in Half the Time

 Why Partial Scrum Application Leads to Quickly Abandoning Scrum

Two years ago, I worked in a startup in Turkey specialized in web site generation. The core team developing the website’s generator was composed of 8 developers, 1 tester, and a Product Owner.

The product had a huge success among the community, but as the CTO put it, “We [were] not able to put any new release in production for more than 2 years,” and their market share dropped drastically to the benefit of their competitors.

During the first three months, everyone in the company was very excited about this new brought-in tool. But after the honeymoon phase, we were facing several issues which made the management doubt Scrum’s real value.

The fact of the matter is “...that Scrum is based on the way people really work, rather than how they think they work,” as Jeff Sutherland wisely put it. And our way of working was lacking some of Scrum’s core foundations regarding bringing the product management and the team on a shared understanding. 

I recall how we ended up stuck many times with one or two user stories for almost the duration of the sprint.

During the sprint review, the stakeholders and the Product Owner were expressing their dissatisfaction regarding the velocity of the team, and the overall outcome of the sprint.

The management even created a “SWAT” non-Scrum team in charge of delivering urgent user stories.

You can easily imagine the team’s level of demotivation and the great distrust that creates amongst the company.

The Need to Reconcile the Team and The Product Management

Actually, the core problem was the misalignment between the Product Owner and the team.

The Product Owner wanted to achieve more functionalities and the team wanted perfection and was unfortunately slowed down by the technical debts cropped up since the product birth 2 years ago. Even though the need of reconciling the business and the delivery team was so obvious and vital, we did not give it the full attention it deserves in the first place, especially during the sprint planning.

It was after a while that we found out that our real Achilles heel was the way we conducted the sprint planning. The sprint planning session done the right way is expected (alongside with the refinement) to guarantee a shared vision between all stakeholders.

For our case, the conversations around the user stories were done as a separate chunk of functionalities, and the team was rarely aware of the bigger picture of how the sprint backlog fits into the final product.

And to make the situation even worse, the selection of user stories turned out to be a race against the clock to “feed the team” without taking into consideration the return on investment.

After a while, the team delivered a shippable product, but this very product did not have the expected value hence frustrating the business.

Our Sprint Planning Event Revamped

As the work emerges during the course of a sprint, some of the sprint backlog items come with their lot of surprises either showing up more hidden/unseen difficulties ones or unforeseen dependencies.

During the refinement and specifically during the sprint planning, we made sure to have all the necessary debates to put everyone on the same page regarding the goals, the investment in time and money and how all these elements fit into the company’s vision.

Hence, everyone knows in the first place and before starting any new user story, why we are doing it and how it contributes to the product success. Some of the epics were even dropped after the team’s feedback either because they were outdated from a market or technology perspective, or the cost of implementation was not worth it.

After that, we needed a tool to make sure that we all stay aligned against any unforeseen surprise we face, and God knows there are many in a sprint.

To do so, we set up some basic rules that helped us achieve this alignment:

1. The selected user stories need to be absolutely in line with the agreed-upon goal;

2. When a new idea emerges during the course of the sprint, unless it is closely related to the goal, it is postponed and not dealt with;

3. Technical debts should be resolved only if related to one of the selected user stories;

4. The user stories should be written in a way to give room for team's creativity;

5. The user stories should absolutely have the acceptance criteria.

How to Avoid Derailing from This Sprint Goal 

The sprint goal is key in defining the direction to head on to during the sprint. 

Actually, the practice of choosing the sprint goal is sometimes not given the consideration it should be due to the exhaustion caused by other activities of the sprint planning. Consequently, the sprint goal turns out to be a random one.

Practically speaking, to craft a to-the-point sprint goal, the following checklist need to be followed:

With regard to the sprint:

1. Has the benefits of the sprint as a whole been identified?  

2. Are these benefits aligned with the overall product vision?

3. Does the team and the Product Owner agree on the importance of these benefits?

4. Can we measure the success of the sprint overall and ensure that the benefits are quantitatively achieved?

With regard to the sprint Backlog:

1. Does every user story selected in the sprint backlog contribute directly to fulfill the agreed-upon benefits?

2. Does the selected user stories belong to a logical set of functionalities (MVP)?

3. Has the cost (as stated by the team) of implementing every single user story been approved by the product management?

4. Can we state clearly what is in scope and what is out of scope during the sprint (including technical debts and non-functional prerequisites)?

Wrap-Up

Applying this simple toolkit will naturally lead to a cyclic exercise from the sprint goal refinement to the sprint backlog construction and vice versa. 

Some of the user stories will get in the sprint and some others will get out and revert back to the refinement session, with the overall exercise resulting in a comprehensive sprint goal, resulting in a better business and team alignment.