who is responsible for establishing project goal

Rajkumar, this is a very poor question you proposed. If this question originated from a source claiming to know Scrum, I would highly doubt that.

Also, the multiple choice options are 1, 2, 3, and 1 (???)

"Projects" are not a part of Scrum. The Scrum Guide states that each sprint should be considered a mini-project in and of itself. If that is the case, we're then talking about the Sprint Goal and not a Project Goal. If the question is "Who is responsible for establishing project goal?", then the answer is the entire Scrum Team (per Scrum guide).

If the question is "Who is responsible for establishing product requirements?", the answer is the Product Owner.

> In Scrum, who is responsible for establishing
> project goal and product requirements?

What answer would *you* give, based on your reading of the Scrum Guide?

What do you think about the quality of this question? Do its assumptions appear to be valid?

If this were a quiz I would choose Product Owner but the best answer is in the scrum guide under the Product Owner role description http://www.scrumguides.org/scrum-guide.html

Hi Rajkumar,

generally in Scrum we do not speak of the whole project's goal. We speak either of a release goal or of a sprint goal. In any case, both types of goals as well as product requirements are under Product Owner's responsibility.

Michael

Organizations which have not established Scrum at the organization level tend to be inconsistent with their definitions. For example, the concept of of product is not clear and instead they still use the term project or program. Sometimes, they mix project goals with Gantt-chart milestones. These organizations in many cases do not have effective product owner who is responsible in crafting an engaging product vision.

Usually, these organizations have no strong concept of product vs project. Generally, come from non-software product industry (e.g. Insurance, Automotive, Healthcare,. Manufacturing,....) and they develop their software through their IT departments. Although there might be some alignment between Business and IT, however, the understanding that Business owns the outcome is weak. Instead, IT reports the progress to the Business while the latter does not assume a product owner role.

In such organizations, Business establishes business goals during pre-project phase to gain approval on the budget. There is notoriously slow cycle from the time of the business need identified till approval is obtained (at least a year). Afterwards, a project is kicked-off with ramping up of IT skills. The project goals are usually inherited from the early established business goals while adding some delivery deadlines.

The idea of project stems from waterfall organizations which seek fake predictability by having the Business develop exactly what they need up-front.

I caution against Release Goals. They are not defined in Scrum and often lead organizations and teams to revert to classical waterfall planning and execution. Each Sprint iteration should be considered a possible release which supports the idea of an increment being fully developed, tested, documented, deployment ready, etc.

A lot of BS in the scrum master universe...However very smart on IT industry to be able to 'reinvent the words'...to make it sound fancy ...repeating the same stuff that has been going on for decades....lol..what a smart way to fool the new generation of 'clients'..