Scrum Story: Inexpensive Experiment

Related image

It is Friday morning 9am. Some of the team members are already in the discussion area. Others are on the way to reach the office. John’s laptop is already been projected on a big screen to make it visible for all team members. Within next 5 minutes all the team members are in. John started to open Jira on his laptop. I looked at the development team and said

Let’s do this differently today. We will try out an inexpensive experiment and see how it works

The team members were clueless what I was talking about. One of them said “Okay. Seems something interesting is around the corner. What is it in your mind?

Me: Anyone of you from the development team sit on the laptop which is connected to the projector. John, come and sit with me. Let the development team sit next to each to other

Observation: The team members pushed one of the developer to the laptop.

Changing the sitting arrangement already brought question mark in everyone’s face except John. Because day before yesterday after backlog refinement, I already shared with him about this idea of experiment and we both agreed to try it out

Image result for sprint planning

John: Okay everyone. Let’s start the sprint planning by sharing the sprint goal. In this sprint we need to go live with the customer form submission

Me looking at the development team: That’s great. So now since we know the sprint goal, let me explain the experiment – Its very simple. This time instead of John you all have the laptop. So you drag and drop all the required stories from the product backlog to the sprint backlog in Jira, which you think should be done in this sprint in order to achieve the sprint goal. If John doesn’t agree with something, he will challenge and we will discuss to arrive at a mutually agreed upon conclusion

Observation: The team members looked at each other. Some still had question mark on their face. The person who was on the laptop looked at John. John had a smiling face.

Me to the development team: Let’s start. Discuss within yourselves and decide which all stories you need to pull. If you think something needs to be added or modified in the product backlog then share with everyone and we can discuss and decide

Observation: The team started discussing the available stories in the product backlog. John leaned forward to listen carefully to their discussion. Initially only some of the team members were involved in the discussion. But eventually the full development team started to participate. During the discussion as and when required John added his inputs. Many of the acceptance criteria were modified.

Whenever the development team pulled one story in the sprint backlog, John had a wider smile on his face. Sometimes while development team was deciding whether they should pull more stories in the sprint backlog John seemed a bit tensed.

While the discussion was still going on at one point of time the development team seemed confused.

Me: What happened guys. You all look confused.

One of the developer: For doing one of the stories which we pulled in the sprint backlog, we first need to upgrade our backend technology. Should we have a story for that. Can we add a story in the backlog. John has not written anything for it.

Observation : John looked confused

John said politely: How am I supposed to know what technology upgrade you need. And if I don’t know it how can I write a story for that

Me to clear the confusion: Okay team. It is true that the product backlog is owned by the product owner. And it is also correct that if the development team has a need to have some additional stories to achieve the sprint goal then they also can add the stories after discussing with the product owner.  So let’s discuss and decide

Image result for pull backlog

Observation: The development team started discussing together with the product owner. Unlike other sprint planning, this time I could see the development team is more engaged in the planning.  Instead of only John trying to make everyone understand the stories, it is a full team effort of helping each other to understand the stories. The development team are thinking through each of the stories. The same stories when discussed during backlog refinement did not raise so many queries.

The team decided on the technology upgrade story and looked at me

Me: Okay. Since its mutually agreed then let’s write the user story

Observation: All the development team members looked at John

Me: Remember, this time we are doing things differently. So instead of John, any one of you write the user story in the backlog

Observation: One the developer started to write the user story. John explained to the development team the format of writing the user stories. While writing the acceptance criteria John discussed the commonly used Gherking format of writing acceptance criteria. The development team was struggling a bit to put the first acceptance criteria. John helped them. The full team contributed to the story which resulted in 6 acceptance criteria.

On completing the story both the development team and John had a happy face. There was a reflection of achievement on their faces

That was the last story to be put in sprint backlog. So the sprint planning ended with a sprint goal, a sprint backlog and a happy team.

Feedback of the experiment from the development team

This time we felt more engaged. We were actually reading through all the stories and trying to find out what all things we need to do to complete the story. For the first time we had a collective ownership of the backlog because we contributed one story in the backlog together as a team. Usually the sprint planning seems like a meeting to us. But this time it felt more like a team discussion where each of the team members were involved.

We learnt how to write an user story. Even though all the stories in our backlog are written in the same format somehow we overlooked it. We never really realized it until today when we actually tried writing it on our own. None of us were aware that the acceptance criteria available in the stories follow gherkin format. This sprint we feel more committed to achieve the sprint goal because it was us who literally dragged and dropped the stories to our sprint backlog by ourselves

Feedback of the experiment from the product owner

Most of the time I used to find this as an one man show where I kept explaining all the stories without really understanding whether my explanations or stories are clear enough. This time when I was on the other side of the table and I listened to the discussions of the development team, I could understand many of the gaps in the user stories which never came out before. This will help me to write the stories in future.

Initially when the development team was moving the stories to the sprint backlog I was little unsure whether they could choose correctly all the required stories to achieve the sprint goal. But once I got involved in the discussion, I did not have to put any effort to check whether all the required stories are being put in the sprint backlog. Because while discussing I understood that the development team are thinking on the right track. Usually I don’t get the opportunity to observe and listen to our team’s thoughts.

Also when I shared with the team how to write user stories and how we write acceptance criteria, I felt a sense of collective ownership within the team. I think this experiment was really helpful and we should repeat it often

Importance of inexpensive experiments

There is an old saying –

To achieve a different outcome, we need to act differently.

Experiments are the ways to act differently. With inexpensive experiments we do not have the pressure to be right in the first time. Usually we don’t need to take permissions for performing such experiments.

Image result for faster feedback

In an experiment if things go sideways then we still get the learnings from it to correct it the next time. Experiments always have faster feedback loops. As mentioned in Esther Derby’s book 7 Rules of Positive, Productive Change

.. because experiments have faster feedback loops, they lower the risk of overcorrection which can lead to crazy-making oscillation

So if we want to progress on bigger problems in a complex situation we have to keep performing smaller inexpensive experiments and learn from it.

Involving people in experiments helps them learn and take ownership. Experiments convey We’re going to try something. It doesn’t imply that life is going to change irrevocably. At the end of an experiment, choose whether to continue, amplify or drop it.

Esther Derby (7 Rules of Positive Productive Change: Micro shifts Macro Results)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s