The Agile Manifesto...huh?

> Yes, we respond to change between sprints, but we follow a plan during sprints. 

We are asked to value responding to change *over* following a plan, not *instead* of.

We are asked to value responding to change *over* following a plan, not *instead* of.

But it seems that Scrum values following a plan over responding to change. We respond to change during our sprint planning meeting, then we follow a plan for the duration of the sprint. The absence of Scrum would involve less following a plan and more responding to change.

But it seems that Scrum values following a plan over responding to change. We respond to change during our sprint planning meeting, then we follow a plan for the duration of the sprint. The absence of Scrum would involve less following a plan and more responding to change.

Hi Ragesh,

How did you get the idea that in Scrum we follow a plan for the duration of the Sprint?

How did you get the idea that in Scrum we follow a plan for the duration of the Sprint?

At our planning meeting we determine all the tasks for the upcoming sprint and the number of hours for each. This is the plan we're supposed to stick to. If the hourly estimate for a task changes based on new information, we can't update it. If we need to add a task, we have to beg for permission to take the hours from some other task (usually a placeholder task that holds unassigned hours for this purpose).

What I would prefer instead, and what I call responding to change over following a plan, would be to write the stories and assign points up front, but then to have the freedom to update or add tasks as details emerge, and to skip the hourly estimates altogether.

> At our planning meeting we determine all the tasks for the
> upcoming sprint and the number of hours for each. This is
> the plan we're supposed to stick to.

Who supposes that? In Scrum the Development Team own the Sprint Backlog including the sprint plan. They can and should adjust their sprint plan, as and when needed, in order to ensure that the Sprint Goal is achieved.

Who supposes that? In Scrum the Development Team own the Sprint Backlog including the sprint plan. They can and should adjust their sprint plan, as and when needed, in order to ensure that the Sprint Goal is achieved.

Well that would be nice. Our product owner thinks she owns the Sprint Backlog. I guess I thought so too, otherwise what keeps the developers from working on stories that the product owner doesn't care about? We don't use Sprint Goals.

If I told the product owner that we (the developers) were going to change the sprint plan as needed, she'd just say no, she needs to know the plan up front. Our Scrum consultant said that as professional developers this is a reasonable expectation for us, and that the people paying our salary can tell us how to work. How do you convince people in power to give up their power?

Is this stuff real? It sounds so out of this world to me.

Off course it is a reasonable expectation for the development team to have a plan for the sprint. It is also a reasonable expectation for the development team to continuously replan, to maximize the chances of delivering useful stuff. A real Product Owner would greatly benefit from such activities. A coordination/"divide the work" type of person, not so much.

Often, alas: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” - Upton Sinclair.

Regards, Paul

If I told the product owner that we (the developers) were going to change the sprint plan as needed, she'd just say no, she needs to know the plan up front.

Your PO needs to negotiate the Sprint Goal with the Dev Team.
She'd like to know that the Dev Team has confidence they can reach the Sprint Goal by having a plan.
But what are the pros for her to "know the plan up front" ?
Doesn't she trust the Dev Team, which is made of professionals, focused and committed people ?

It is important that you consider when the Manifesto was written and what were the prevailing views on how software development should be managed and organized.

At that time most companies were pushing hard methodologies which involved a huge amount of documentation and many large corporations were busy building armies of people whose job was to create such documentation. In some cases there would be huge (encyclopedia sized) tomes of information in written or diagram form created about software that would never be developed as the business requirements had changed too much while all this material was being created.

It was in this environment that the Manifesto was created. It is not meant as a call for the second set of things/actions to be discontinued, just that the first is more important and thus should be prioritized.

Consider that today you are discussing changing the plans created for two, or three week long sprints. At that time we were discussing plans which might refer to six months or more. You can probably see that even if you only review your planning every two weeks, that is a major advance against doing it every six months. :-)

Of course, the pace of change is only accelerating, so it seems only natural that you might consider two weeks as too long to wait to review your work plan.

Sounds like the PO could do with a refresher course in Scrum

> Is this stuff real? It sounds so out of this world to me.

Which part sounds out of this world? None of this seems all that unusual to me.

> But what are the pros for her to "know the plan up front" ? Doesn't she trust the Dev Team, which is made of professionals, focused and committed people ?

I don't think it's an issue of trust. She needs to know the total number of hours up front, because that's how she decides what we can fit into the sprint.

> It is important that you consider when the Manifesto was written...

Good points.

> Sounds like the PO could do with a refresher course in Scrum.

To this company's credit, they're making a much better attempt at Scrum than the last place I worked, which had daily standups but no sprints, no regular reviews and retrospectives, no Scrum master, and no product owner.

I don't think it's an issue of trust. She needs to know the total number of hours up front, because that's how she decides what we can fit into the sprint.

The goal and content of the Sprint is not decided by the PO on her own side but by the whole Scrum Team.
The Dev Team is not made of stupid robots. Your PO should collaborate with the Dev Team, otherwise she will destroy the Dev Team commitment.

Again, why does she need to know the plan up-front ?

Posted By Olivier LEDRU on 06 Oct 2014 01:38 PM
Again, why does she need to know the plan up-front ?

Well, I don't think she needs to know the plan up front, but she thinks she does. That's because without having the total number of hours, she can't decide what stories go into the sprint, do the burndown chart, and report the hours to senior management.

Now you say that the product owner is not supposed to decide the goal and content of the sprint on her own, but it should be a team effort. Makes sense. But our PO was a project manager before Scrum; she's the current boss of some of the team and the former boss of the others. Going from a project manager who owns the team to a product owner who works with the team is a demotion, so why would she go along with that? Isn't this a common problem?

Hi Ragesh,

It is common in an organisation who does not yet understand the value of Scrum and just maps traditional project management to Scrum. In Scrum, the Product Owner and the Dev Team works together as one team instead of as boss-subordinates.

Posted By Ragesh Patel on 06 Oct 2014 01:00 PM
I don't think it's an issue of trust. She needs to know the total number of hours up front, because that's how she decides what we can fit into the sprint.

I think this is the problem. The Product Owner should not be the one deciding what goes into a Sprint. The Product Owner should prioritize the items in the backlog, but it's the entire scrum team should have a discussion during Sprint Planning on what to include in the Sprint.

I'm wondering does the team also estimate the backlog in Story Point or other type of sizing other than hours? The team should be able to estimate the size of the backlog items. Not in hours but in relative size. During a sprint the team is able to finish a number of story points. This is the number the PO should use to determine what could possibly go into the next sprint.
The team then desides what work needs to be done for each item to determine if the work that is needed will fit in the sprint so they can discuss with the product owner if less or more items can be added to the sprint. If the PO en teammembers agree then a commitment based on best effort can be given.

It is the responsability of the team to do what is nessesary to finish an item. So adjusting the plan is mandatory because you don't know everything upfront.

Posted By Paul Kuijten on 04 Oct 2014 03:20 AM
Is this stuff real? It sounds so out of this world to me.

If at first the idea is not absurd, then there is no hope for it.

- Albert Einstein

If you neglect to entertain absurdity, you're ruling out many potentially great ideas!

Posted By Pieter Versteijnen on 17 Oct 2014 04:59 AM
I'm wondering does the team also estimate the backlog in Story Point or other type of sizing other than hours? The team should be able to estimate the size of the backlog items. Not in hours but in relative size. During a sprint the team is able to finish a number of story points. This is the number the PO should use to determine what could possibly go into the next sprint.

Yes, I'm trying to get them to do that. Right now we estimate the stories in points, we enter the points in TFS but then never use them for anything.