2

Consider this scenario:

Stakeholder(s): Let's build a web application to manage user's financial data.

Scrum team: Ok, let's do it. . . .

After 3 sprints

Stakeholder(s): Let's also implement a mailing system, so that when user's financial status is not good, (s)he would be warned.

Scrum team: Ok, it's not that hard. We'll do it. . . .

After 5 sprints

Stakholder(s): Let's become a mailing provider.

Here, how should scrum team guide stakeholder to stay inside the scope of scrum vision? Maybe a more fundamental question is, should the at all?

Update: Of course there is a product owner. But by scrum team I meant PO, SM, and Team.

Improve this question
3
  • 2
    Who's the "Product Owner"? More importantly, what input are they providing to guide the stakeholders and the developers? Is there a product owner? If not, why not? If so, what input are they providing?
    – S.Lott
    Jul 26, 2011 at 14:09
  • 3
    Stakeholders are not there to meet the scrum vision - the scrum vision is there to support the stakeholders, and their requirements in an effective manner.
    – Chris Walton
    Jul 26, 2011 at 14:19
  • 1
    Is this a problem? I don't see an actual problem with modifying the "original" vision. Isn't is possible that the "original" vision was wrong because it was so limited? Isn't this simply "can the Product Owner change the product"? Is the answer simply "yes"? I don't see what's wrong or broken.
    – S.Lott
    Jul 26, 2011 at 14:48

4 Answers 4

Reset to default
9

The very purpose of Agile methodology and sprint development is to support the new and changing requirements of the stakeholders. If this project were being managed in a waterfall way these kinds of request would threaten the success of the project.

If there is one thing that I learned, You can't fight scope creep. It is like swimming against the current of a river, you can fight and kick and scream all you want but in the end the river will sweep you away. The bottom line is that the stakeholders want is what should be delivered or the stakeholders will be unsatisfied.

A further advantage of your situation is that they are not changing established requirements, just expanding the scope to include additional features. This is fine as long as the deadline moves forward with scope creep. This only becomes threatening to a project when a firm deadline is set.

Improve this answer
7
  • This seems so deterministic, and frightening @maple_shaft :)
    – Saeed Neamati
    Jul 26, 2011 at 14:12
  • 2
    @Saeed: what's frightening about this?
    – wolfgangsz
    Jul 26, 2011 at 14:17
  • 1
    The notion of "scope creep" @maple_shaft. I upvoted your answer, cause I liked it. But my utopia was the world of no change in vision (even in scrum). However your answer suggests that change is everywhere.
    – Saeed Neamati
    Jul 26, 2011 at 14:19
  • 2
    @maple_shaft well said, exactly what Agile is supposed to do. The deadlines can be a static date in the future you're building features towards or a floating measure of the current feature set, as long as everyone knows and agrees what the deadline is.
    – Patrick Hughes
    Jul 26, 2011 at 14:19
  • 1
    Yes deterministic but only frightening depending on your perception. According to Chinese Taoist philosophy, life is a river and the current of life takes you where fate determines you should go. If you fight lifes path you delay the inevitable and possibly accelerate your demise. This is frightening for some because it removes the illusions of control that people maintain, but TRUE POWER comes from knowing how little control you really have. This does not mean to not try, just accept what you have control over, what you can influence, and what you cannot and you will be empowered. :)
    – maple_shaft ♦
    Jul 26, 2011 at 14:24
4

For each new feature, explain that it will push back the date of release, and increase the uncertainty of the release date. Time is money.

"Yes SIR, Mr. stakeholder. Of course, Mr. stakeholder sir. I will deliver the world to you on a silver platter. And all I ask in return is for you to pay me to work on this project until I'm 50. Because that's how long it's going to take."

You could also mention that every hour that the stakeholders spend hammering out what all the requirements are is about 10-20 hours of development after it's all said and done. Knowing about requirements upfront and planning for them is more time-efficient then bolting solutions onto the side of a project.

Improve this answer
1
  • 2
    ...until 50? I could handle a two year project ;)
    – JeffO
    Jul 26, 2011 at 15:51
2

I think it's fine, as long as you're re-evaluating the new goals in light of the old ones.

I'd say that as soon as your stakeholder wants a mail server the team might do one of two things:

  • double check that a mail server is more important with the previously defined features in the backlog for the financial data app. If the business side stakeholders agree, they are the experts in the problem domain.

  • as a team, see what you can do besides develop a mail server - obviously this is an extreme example - but it'd seem intuitive to host a mail server that has already been developed and you may still have time in the sprint to proceed with the original goals, too.

I know a lot of times there's a desire for immediate gratification vs. long term goals. And I think for big stuff that can't get done in a single sprint, the team is definitely challenged to break up the long term stuff so that it still seems enticing compared to the short term easy adds that seem important but may not be.

Improve this answer
0

Why stakeholders are communicating with the team rather than just the PO. Anyway here is how i think PO should handle this situation. First a quotation from Ken Schwaber's book "Agile Project Management with Scrum"

A Scrum project starts with a vision of the system to be developed. The vision might be vague at first, perhaps stated in market terms rather than system terms, but it will become clearer as the project moves forward. The Product Owner is responsible to those funding the project for delivering the vision in a manner that maximizes their ROI.

So PO must inform sponsors, i.e. stakeholders, how deviation would affect (or delay) ROI. If sponsors are okay with this then the team cannot have any objection.

SCRUM stops scope-creep during the sprint i.e. not during the release. In fact a good PO will ensure that any changes in outside factors, including in the mind of sponsor, are correctly reflected in the product backlog ASAP.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.