A team needs their OWN rules to deliver value each sprint

In life and in work, we all rely on experiences and especially if we experience something everyday for a considerable amount of time. But sometimes, it’s good to reflect on how those experiences affect us and change our ways.

Context:

A little while ago, I joined a team (Team Skywalker) as a Scrum Master. This team was working on developing a new product and had a ‘milestone’ planned for when they wanted to release to production.

The team members were great, motivated and expert at what they did. The problem (which they were already trying to solve) — they were not playing by their rules. Why? Because some time ago, someone (read: a manager) set these rules for them to play by. They followed these rules for a considerable amount of time, which then became a part of how the team functioned.

The Problem:

During the refinement (part 2, where the PO was not present), the development team was looking into the epics, in no particular order (provided by the PO) and creating stories based on the aforesaid epics. These stories were then being broken down into tasks with acceptance criteria (written by the development team without a business representative present) and then these broken down tasks were being estimated.

Then in the planning, we would look the estimation on the broken down tasks and take a bunch of them that fit as per the ‘velocity’ of the team. This led to a number of tasks being prioritized and worked on, instead of delivering value to the user.

We encountered the situation where the team was working on a lot of things but since they were only parts of user stories; this led to the question — what was the value we were delivering each sprint ?

The first steps towards the light:

The team recognized and brought up in the retrospective, that their ways of working could be improved, to focus on maximizing the value delivered at the end of each sprint. So, we decided to focus on the below points:

• Deliver user stories in sprint (and not broken down tasks).
• Estimate user stories (and not broken down tasks).
• Do the task breakdown after the sprint planning (1).
• Come up with our Definition of Ready (DoR) and Definition of Done (DoD) and start following it.

We also made an agreement to follow the above points going forwards, which meant the work that we ‘estimated’ before, we would complete it without over-complicating things.

The solution begins:

We got together in a room and wrote what we felt should be our DoR and DoD. Nothing fancy, but basic agreements which we promised to adhere to. Example: we should know value of the work we need to do; the story is refined and estimated etc …

Next up was how to refine and estimate stories:

In the refinement we realized we have no idea how to look at user stories as a whole and talk about it. We were falling back to talking about it as Front-End vs Back-End development and we realized we need to understand how to look at and compare user stories in a better way. We also realized that our refinements were running too long and everyone was exhausted by the end.

How did we fix this?

We did an exercise to look back at the user stories (which means all the broken down tasks), we delivered in the last 3 sprints and tried to compare them to each other on the basis of ‘effort’, ‘complexity’ and ‘risk’. This helped us achieve two things:

• We understood how we wanted to compare stories as a team.
• We set our reference stories.

We also knew that we wanted to revisit them every 2 sprints to do the same exercise and get better at relative estimations.

Next up? We scrapped our once-a-sprint refinement sessions and started doing daily/lightening refinements for 15 mins every day, where we came together and spoke about (and tried to estimate) only one story every day. If the discussions ran longer we did them asynchronously and if required, picked up the same story the next day as well. It took us two weeks to find our rhythm but in the end we knew what it meant to deliver value in a story and estimate it.

In the sprint planning, we still had those old tasks to work on which we had agreed not to invest more time refining; but we also picked a couple of new user stories and tried to deliver them.

What Happened? We could not deliver any of those user stories because we learnt that working together, focusing on one story, meant we needed to collaborate more, come to decisions together and be aligned with each other during the sprint.

People started having doubts, some even wanted to revert to the old ways and conflicts started coming up (which were resolved within the team and by the team members themselves, Greatness!!)

But we didn’t give up …

We kept on pushing each other, helping each other out, we went away from talking about developers job vs QAs job, front-end vs back-end; who is responsible for which column.

And we came to a place where we were swarming a story to see what is required to complete it; who has time/is needed; to review, to QA, to approve, to coordinate.

We had our first successful sprint with only user stories (where we reached the sprint goal) after 3 months of letting go of our past experiences and adapting to our new ways of working. We focused on releasing the ‘increment’ at end of each sprint to the user, which means more frequent (and predictable releases); and changed our DoD to match it.

And every sprint, every retrospective we still look at ways to improve further (and we have a long way to go …)

The big reason this worked was because the people were motivated, were willing to figure out a way to improve and had trust towards each other. It all starts with trust and it’s only upwards from there.

Robert Kalweit : Thank you for your help getting this out!