-1

I'm learning the Scrum Process. For the order of events in the Scrum process, which comes first product vision or traditional requirements?

I know that once the product receives the requirements it is backlog and prioitize by having a sprint log but I'm fuzzy in the arena of vision and traditional requirements.

Minimalist
  • 963
  • 12
  • 34
  • 4
    I'm voting to close this question as off-topic because [project management is now off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (You can also flag for moderator intervention to have this question migrated.) – robinCTS Oct 28 '17 at 02:15

4 Answers4

1

First of all could you please define "traditional requirements"?

In general the natural order of flow would be vision -> product backlog. An initial vision gives some focus as to what's going to be important (to the customer) in this release and therefore helps to shape and prioritise the requirements. The vision should address the fundamental question: "Why will customers buy this product?".

But remember that Scrum is an iterative, incremental process so the backlog and vision may be constantly evolving, taking in various different sources such as Voice of the Customer exercises, bug reports, comments from sprint reviews etc.

Regards

MelR
  • 23
  • 4
1

SCRUM is about how you handle your project.

The envisioning process comes before the project itself. It is pretty much possible that there may be no project, and therefore no SCRUM. Gathering requirements (generating your product backlog) comes when people are done with envisioning and found out that starting with the project makes sense. This said, you will find it logical that product envisioning comes before gathering of the requirements, because people may not bother with requirements if in the middle of envisioning process they realise there is a same/similar product out there, or that it is not feasible to do such thing.

Example:

Envisioning process: Person X says - Let's make a teleport machine. With it people would be able to instantly transport themselves to any point on The Earth. Person Y joins and says - but that is impossible because of {blah, blah, all those scientific reasons}.

Naturally, they give up. :)

Requirements gathering: No need, because they realised the project is doomed to fail during the envisioning process.

DejanLekic
  • 18,787
  • 4
  • 46
  • 77
-1

Based on my experience both the product vision and the requirements (be them functional or non functional) are to be expressed inside the Product Backlog. How to prioritize them is a Product Owner decision. The Product Owner is the only person allowed to decide the priority of a "nice to have feature" over a "required feature". To help you get an idea on what to include in the Product Backlog have a look at Mountain Goat Example Product Backlog as you can see the Product Backlog includes both:

  • As a site member, I want to describe myself on my own page in a semi-structured way. That is, I can fill in predefined fields, but also have room for a free-text field or two. (It would be nice to let this free text be HTML or similar.)
  • As a site visitor, I can view lists on the site of all Certified ScrumMasters, Practitioners, Trainers, and Certified Product Owners. (The CSM list has over 5,000 names so a letter-based pagination approach is needed.)
-1

So, the question is: In Scrum, Which comes first:Requirements or Product Vision?

Answer: whichever comes first in any other methodology.

Product Vision has nothing to do with scrum. It is the vision that you have for the product and would be the same irrespective of the methodology that you choose to follow. So, even if you follow waterfall, you still need a product Vision or Roadmap.

In Scrum, the Product owner would break down your product vision into user stories (requirements in the user's language) and prioritize them on a regular basis.

Hope that helps.