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.
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 !
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.