Scrum 2.0

Follow the leader
Follow the leader

First of all I would like to apologize… I’m really sorry… for such a “buzz title” in this post ;-) Okay but, let’s see what’s beyond this “Scrum 2.0” expression.

In the project we worked 6 months using Scrum, the release was done and we had one month off. After the one month off, we were supposed to continue working on the same project with a second release in the next 6 months. Before starting, we took the opportunity for a lessons learned about our 6 first-months of work. One point was about the way we work in Scrum mode. Should we do exactly the same during the next 6 months ?

Something came up quickly. Some team members found the process of dividing a user story into tasks (+ estimate the task in hours) very heavy. I took the feedback and met each team member individually. We discussed the positive points and what could be improved. Then I checked if all the team wishes matched my Scrum master needs and constraints. Then I came up with a different way of working. We used the Scrum 2.0 method with success in the second release.

Scrum 2.0: How does it work ?

Before we start, some prerequisites:

  • Team remains the same (or almost). In our situation, we had one new team member.
  • In the last 6 sprints, team became more and more autonomous.
  • Productivity of the team improved at each sprint.

Here’s what was done and how our way of working evolved.

1. No more “ breaking the requirements into tasks

We no more broke the requirements into tasks. However we kept the concepts: User Stories and complexity (Fibonnacci). We didn’t give up on post-it notes: If some tasks seemed important, we wrote those tasks or some “attention points” on post-it notes. And then, as usual, we sticked those notes on the corresponding user story.

2. User Story leader

For a user story to be done, here’s how we do it. First team member who takes the user story is considered as the Story Leader for this specific user story. To make it clear (and visual) for everybody, he sticks his color on the user story and draws a star on it. The star means, that this team member is the Story Leader for this specific story. See also “Scrum 2.0 illustrated” figure for more details.

Scrum 2.0 illustrated
Scrum 2.0 illustrated (click to enlarge)

Story Leader is responsible for this Story, which means two important things. One, if several persons have to work on the story, the story leader will coordinate and follow up the progress. Two, story leader is responsible for the information and the communication, he speaks during daily meeting. If Scrum Master or Product Owner have questions on a story, story leader know the actual situation and can immediately give infos and details.

For instance: Scrum Master asks to Soulira (Story Leader for Story #45) “How far are we with Story 45 ?”

Bad answer: “yup, I don’t know, Vincent is actually coding this story, you should see with him…”

Good answer: “Vincent will end coding this afternoon, then I will update the design, you can consider it done for tomorrow 5 p.m.

3. Web Analyst

In our 1st release, the 6 first-months, we had specs with a functional analysis. Therefore, we created our product backlog based on those specs. This had the advantage, that the specs were validated by all the stakeholders (client-side). However, in the second release we had to restart from zero, without detailed specifications. And we needed our user stories to be ready asap for the team to start development. An additional issue, that could cause delay, was that the product owner had to validate priorities with a work-group.

To fix these potential issues, I decided to create the Web Analyst role. What is he supposed to do ? He has a month to help the product owner writing user stories and prioritising them, in order they discuss them with the work-group. Once finalised, the user stories are ready to be presented to the team.

Example: In January, the web analyst worked with the product owner and the work-group. End of January, we did the sprint planning together. We then discussed on a set of user stories already negotiated with the clients. On February, 1st, we could start the sprint.

To summarize, role of the Web Analyst is to be one-month ahead to the rest of the team.

Why should we change our way of working ?

For us, this change in our way of working was a success. One benefit was to reduce the risk of frustration of the team regarding the “breaking the requirements into tasks” actions. The other benefits was that the team members were more “responsible” and took the lead on the project.

I remember, at the very beginning, even before questioning our way of working, I was desperate. Things were not going so fast and so well the way I wanted. Agile Principles were not correctly applied… I remember discussing with an Agile coach and he told me: “Look it’s normal, you will see, at each sprint, the team will gain in efficiency” . Indeed, starting sprint #3 I was reassured things were getting better and after the first 6 sprints we did 6 additional sprints using our “Scrum 2.0” method.

In a project it is necessary to evolve or to adapt, that’s why Agile and Scrum have feedback and review mechanisms. By applying those mechanisms I was able to set-up a new way of working for the team. How was I able to set this up ? Simply by listening to my team members. Do not underestimate the power of feedback, sprint review and lessons learned !

See you soon !

Bruno.

Ps: I wouldn’t advise a fresh new team to work this way, but it’s a good basis for an experienced team who wants to work in a slightly different way.



This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.

Laurie Young

Bruno, thanks for a good post. Its a great example of a team evolving scrum to better suit your needs. I especially liked your Story Leader idea, and plan on trying it to see if it gives us the same distributed responsibility.

We have experimented with no task breakdown, and find that it results in less continued commitment during a sprint. I use the task breakdown (with hour estimates) to continuously answer the question “Are we going to complete all the work in this iteration?” – how do you answer this?

Finally – I am unclear on the difference between your Web Analyst role, and the Product owner role. Can you elaborate on this?

brunosbille

Hello Laurie and thanks for your comment !

For your first question, i agree with you: task breakdown will surely help for commitment during a sprint. Actually i did the same as you do. I’ve tried without task breakdown and in my case it worked. Maybe because the team was already in place for a long time (+6months) We also did some team building to improve our cohesion and commitment.
Anyway what you did is a excellent practice: you’ve tried something (no tasks breakdown) and after a while you drew some conclusions and decided to rollback, fine for me.

The Web analyst is there to support the product owner, in our context it was useful because the product owner was “junior” in project management and was not staffed 100% on our project. So the web analyst mainly assist the product owner. If the product owner has a specific need, he also discuss with the team to propose different scenarios (technically possible) to the PO.

Does it help ?

Cheers,

Bruno.

brunosbille

I’ve still one thought,

How “Are we going to complete all the work in this iteration? “, we use the sum of the complexity points.

e.g. We know that the team in 4 weeks can achieve 135 points, so we don’t select more user stories than a sum of 135 points of complexity.

Normally this sum will increase at each sprint, you team will improve his productivity.

Bye,

Bruno

Your email address will not be published. Required fields are marked *