While I was working at Intuit, a developer asked me what was next, after Scrum. He related that Intuit had built its own waterfall methodology. Then Inuit bought a commercial methodology. Then it moved to RUP. Then it built its own Agile process. Inuit was now using Scrum. What did I think that Intuit would use next? I pointed out that what Intuit used next did not matter. The point of Scrum was to become a world-class engineering organization, not a consumer of methodologies and processes. If Intuit didn’t improve its software development practices, it actually didn’t matter what methodology it used next.
I’ve noticed that many developers and managers view Scrum as the next methodology to endure. While enduring Scrum, they continue doing the same things they always have done, just to get the job done.
People often don’t view Scrum as a tool they can use to become Agile. They view Scrum as another methodology that they have to layer over their real, unchanging work. Getting a release out the door is all that counts. This approach is simple, because no real change is required. Unfortunately, none of the anticipated benefits accrue.
I’ve gathered some examples of how people try to layer a new process over their old way of working.
Example 1: I attended a retrospective. The room was dark. The Scrum Master was projecting the “retrospective” form from Version One on the front wall. Team members called out things they liked or didn’t like from the last Sprint. The Scrum Master typed them into the form. When enough entries had been made, the meeting ended. I asked why they were recording the likes and dislikes. The Scrum Master said that Version One had a form for this, so it must be important.
Example 2: I attended a Sprint Planning meeting. It was abbreviated to one hour. The previous week, the Scrum Master assigned Product Backlog items to each Team. Each Team member decomposed his or her Product Backlog items into tasks. The Sprint Planning meeting consisted of the Team playing planning poker to estimate the tasks. They were then uploaded into Jira as the Sprint Backlog. This fascinated me. I knew the entire Scrum Team would estimate Product Backlog items. However, the idea that everyone else on the Team would estimate how long it would take for you to do your task was inappropriate.
Example 3: At another Sprint Planning meeting, the Product Owner reviewed the releases’ remaining Product Backlog. She and the Team then calculated the number of Product Backlog items (PBIs) remaining. The Team would have to complete that many each Sprint to be done by the release date. The Team then committed to do that many PBIs for the upcoming Sprint. Since the number of PBIs was greater than what the Team could fully complete in a Sprint, the Team planned to reduce the definition of “done.” This allowed them to finish all the required PBIs. No one discussed when the “undone” work from each Sprint would be done.
Culture persists. We’ve spent years developing habits that allow us to cope with waterfall. We are now using the same habits to cope with Scrum.
Ken Schwaber's Blog: Telling It Like It Is 
> However, the idea that everyone else on the Team would estimate how long it would take for you to do your task was inappropriate.
Ken,
Why is it inappropriate for a team to estimate tasks as a team?
From the Scrum Guide:
> The Team self-organizes to undertake the work in the Sprint
Backlog, either during the Sprint Planning meeting or just-in-time
during the Sprint.
In theory, the team may not know who will actually take on a particular task in the sprint, so wouldn’t it make sense for the team to work together to create the estimates for tasks?
Something else you said, using Planning Poker to estimate tasks is pretty dangerous, IMO. PP is meant to size Stories using Story points that represent real value to a stakeholder. One could apply a similar theory to estimating tasks, but then what units are the estimates in? How do you update your Burndown?
Burndowns work for anything, as long as the work is denominated in the same units as the velocity. Even megaquatks.
This team was estimating all the tasks. That represented the time allocated or reasonable for whoever got the task. Estimating Product Backlog items this way is appropriate, because we are trying to get the Team’s estimate, since the Team will be doing the work. It is inappropriate for Team to estimate the length of time an individual will spend to perform a task.
Ken
I’m having trouble understanding this. If my team is totally cross functional, and the team doesn’t really know who will work what task until the task is taken up just in time during the sprint, who is this individual that estimates tasks?
Do you just have one person who might be doing it estimate it, then when a different person picks it up and feels the estimates are incorrect should they just re-estimate at that time?
I’m not saying the whole team sits around and estimates one task at a time.
An example:
At one client, in the second part of the SPM, a team would divy out the stories, one or two for each developer. Each developer would then estimate what tasks are needed, as well as how long they would take (they used hours)(This all happened in the same room, btw). Then, the team ‘rejoined’ again, and tweaks were made as the entire team had influence on the task estimates, as well as the identified tasks. At that point, they had a sprint backlog, and generally speaking, no matter who picked up the task, the tasks rarely needed re-estimating.
Is what I described acceptable or inappropriate way to estimate tasks?
First … what I was describing was a mis-application of Planning Poker. The Team thought that since it was used to estimate Product Backlog, it should also be used for Sprint Backlog. I disagreed.
Second… you are correct, the Team is cross-functional and self-organizing. What I’d like to see in the second part of the Sprint Planning meeting is for the Team to figure out how they are going to turn what has been committed to into something done. This often starts with a design session, using a whiteboard. As the design or approach emerges, I often hear Team members say, “I’ll do that” or “I’ll do that, but can you also help me with this?” as Team members commit to tasks. The tasks are reflection of turning the design into the increment. Planning poker implies that others get to estimate a task that I might take on, whereas when it is used for the Product Backlog, the whole Team is taking it on.
If the Team is deriving or hypothesizing tasks that don’t yet have an owner, either just stub out or put in something that seems reasonable (within ten seconds). Then when someone picks up the Task, that person can do the estimating.
The other question is, why does the Team have to come up with estimates for the Sprint Backlog tasks prior to knowing who will do the work. My Teams often leave the Sprint Planning meeting with only 50-60% of the Tasks estimated and people signing up for them.
Ken
Yes
Totally agree that PP is inappropriate for task estimating. My questions relate more to the sprint backlog, tasks to get to done, and the spring backlog burndown.
> either just stub out or put in something that seems reasonable (within ten seconds)
Can you expand on this? Does this “stubbed out” thing have an estimate always, sometimes, never? I’ve never fully understood what this (“…stubbed out…”) sentence means in the Scrum Guide. I do understand the part about
> The other question is, why does the Team have to come up with estimates for the Sprint Backlog tasks prior to knowing who will do the work?
I’m not saying they have to. I’m just saying this team did, and since their sprints were 2 weeks, they felt fairly comfortable trying to identify close to 90% of the tasks at the SPM itself. They chose to wait for task signup(or ownership as you called it above) until inside the sprint itself(something recommended by other sources, and I had always interpreted that snippet above from the Scrum Guide to mean something similar). I should also make the point that they, on occasion, would re-estimate tasks, re-task items, etc inside the sprint, whenever they felt it necessary.
What I was trying to get answered was, is the way this team (in my example) did it (based on the context I’ve offered) inappropriate insofar as their method violates what the Scrum Guide says or what you intended in the SG.
Correction:
> I do understand the part about
should read
> I do understand the part about “…given large estimates that will be decomposed later in the Sprint….”
Estimating not only gives valuable information for velocity and planning, but beyond that, it is a great opportunity for the team for gaining information about the matter being estimated. An individual can be biased if their Team mates take part in the estimation of a task, but still, I think it can be valuable to let the Team have a look at the task and share their impressions.
Planning Poker can be a vehicle to facilitate this process at the Product Backlog level, but while reading this thread I’m realizing that at the Sprint Backlog level it can alter the estimation in non-desirable ways. So it would be better to gain information on the tasks by means of simple conversation during the Sprint Planning, but not getting to the point of agreeing on a group estimation. Would it be a good approach?
Part of the problem are overly complex Scrum/Agile tools that force people to fill in different forms, have elaborate backlog hierarchies itp. That coupled with abuse of those tools by managers leads to people seeing Scrum as a methodology with its own set of tools one has to “service” – and do their proper job in the time that remains.
But there is one more dimension here: young people who enter the profession are not spoiled by waterfall habits – so they have nothing to unlearn. As I have experienced with my team for them working the Agile way was the only way they knew and it was all natural for them. Only now some of them who have moved on elsewhere are discovering that things can be done in a bad way – and running away from those places or trying hard to change them.
This is how the change in the industry as a whole begins – all of the ppl that I had a chance to form in this fully agile environment will go on in their careers until some of them will become managers and will be able to directly reshape their companies/teans. I believe there are by now hundreds of SMEs like mine doing the same thing – showing people how things can be done, how work can look like – and then, in the natural order of things, sending them away elsewhere thus spreading those values and way of work. This is how Internet got outside of the campuses, this is how Linux got corporate acceptance – now it is turn for agile.
I realize my comments above were confusing. The team I described, when tasking out, left it up to individuals to create and estimate tasks, which usually took about 10-20 minutes or so in the SPM, and design discussions were had when needed to get to the tasking. Then, when the team sort of ‘rejoined’, some estimates(especially by those who may end up doing the work) were discussed very briefly. The entire “tweaking of estimates” usually lasted 5 minutes or less, primarily because everyone knew they could change those estimates and/or re-task whenever they so desired within the sprint.
Hopefully that’s clearer than mud.
Ken,
Thanks so much for the answers. As a PSM I, I’m trying my best to represent your view of Scrum!
> My Teams often leave the Sprint Planning meeting with only 50-60% of the Tasks estimated and people signing up for them.
If you only estimate 50-60% of the work, it would seem that your sprint burndown chart would look weird in the first part of your sprint, and any trend line(as discussed in the SG) you draw would probably not be very accurate or useful as it doesn’t represent all of the remaining work.
It would seem to me that the only terribly useful trendline would be one where all or near all of the work was estimated for the entire sprint, even if those estimates include a “placeholder estimate/task” that will be broken down later in the sprint into tasks that generally last less than one day.
What is your advice on this?
Ken,
I saw your keynote speech at Agile Tour Montreal about “what Done means” and it was excellent! We have a good talk about that internally.
Now about your post, I think the key here is education adn changing the mindset of project management.
I work with Planbox, an agile project management tool and we see all kinds of stuff from users, developpers, project managers… everyone seems to have their own interpretation of what Agile and SCRUM methods are!
Let’s keep in mind that Agile methods are still in their early adoption stage and as more and more users get educated to it, I think the dust will settle… until the next method comes along.
– Alex
If we don’t get our skills and habits straight, it doesn’t matter what the next process is.
Ken
Pingback: 5 Top-Blogs zu Scrum und agiler Softwareentwicklung « Produktmanagement und Vermarktung von Internet-Anwendungen
Pingback: The Bradley Agile Maturity Model « The Scrum Crazy Blog
Pingback: Debunking Myths about Agile terms | Software Cookie
I just found this blog post. It is really interesting. We are still seeing this today in 2018. People have their own interpretation about what Scrum is. These days it is quite common to see people use Scrum as mini-waterfall.
Quick question on Planning Poker, I understand that using it in part 2 of planning may be too granular.
I believe poker in refinement is too early and prefer to run it in Part 1. At least in NZ this is a minority view. My rationale is that INVEST suggests estimABLE and not estimated. Small has provided indicative sizing to be ‘probably less than a sprint’
Would like to hear your views on this.
You seem to be well advanced in the practices that supplement Scrum. You do seem to be focused on planning. I tend to rely more on empiricism to do a lot of the planning, providing solid feedback of what is possible and probable. Oh, I also rely heavily on my teammates.
Ken