Detailed Requirements Gathering - Help

> At what point does the detailed requirements
> gathering take place to be able to estimate
> and commit to completing this story in a sprint? 

Requirements gathering and estimation can happen at any time, though a Sprint Review is a formal opportunity to consider the work remaining on the Product Backlog.

Deciding which riequirements to action in the upcoming Sprint is one of the topics addressed in Sprint Planning.

Thanks Ian for the input. I do appreciate it as I work for a waterfall shop and we're exploring Agile/Scrum but we're collectively struggling with conceptual change in processes.

So in waterfall I'm used to having access to some business SMEs or something similar. Is the product owner my ONLY contact with the company? Do companies really have product owners that know the line-level business well enough to answer detailed questions about day-to-day activity? My fear is that we'd communicate with the PO and he/she wouldn't know the info we normally collect from the business SMEs and then we'd end up doing everything multiple times. I get that being agile with requirements is the part of agile methodology, but I assume that being smart is built in there as well.

Again, I'm very interested in this process and I'm not being negative. I see huge benefits but I want to be able to answer these questions internally as they come up.

Thanks,
Micah

> Is the product owner my ONLY contact with
> the company?

No. It's fairer to say that in Scrum the PO is the only business contact you absolutely have to have, and that he/she must be the final arbiter on matters of business value and return on investment.

Relationships with other stakeholders can still be cultivated, and should be if the PO believes it will increase the quality of the product. For example, the PO may invite such stakeholders to the Sprint Review if their feedback is thought likely to be valuable.

> Do companies really have product owners
> that know the line-level business well enough
> to answer detailed questions about day-to-day activity? 

Yes. A PO isn't expected to be a walking product encyclopedia, but they are expected to be able to provide sufficient information to the Development Team in a timely manner. In other words what they don't know, they'll find out.

Yet even this can be a challenge, and many teams end up being short-changed. Establishing Product Ownership of sufficient quality to do justice to the envisioned product is often politically difficult. Sometimes weak product ownership is a contraindication to the product being developed in the first place, and should be seen as such. If nobody wants to own it, or it isn't important enough to be properly represented, should the associated project go ahead at all?

This statement is not quite accurate:

> Deciding which riequirements to action in the upcoming Sprint is one of the topics addressed in Sprint Planning.

According to The Guide:

The Sprint Review includes the following elements: ...
The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;

IME, if you wait until Sprint Planning to decide what will get done, no one is prepared to complete the planning meeting (or it's at least far less efficient). Having an idea of what is intended allows people to start thinking about how it will get done and they will show up at the Sprint Planning meeting better prepared. Not that it can't change, but to show up on Monday morning and ask "what are we gonna do next?" for the first time, it won't go well.

> if you wait until Sprint Planning to decide what will get done...

As the Scrum Guide indicates, the team can and should collaborate on what to do next in a Sprint Review, but the decision on what will get done in the upcoming Sprint is not made until Sprint Planning. Note that this decision takes the form of a forecast rather than a commitment. The Sprint Review is an opportunity to broadly consider what to do next in the sprints that remain, although no forecasts will be made.

As a general rule for a story to be included in a sprint backlog (from product backlog) during the sprint planning meeting, the development team should feel that it has sufficient level of details so that it can be implemented during the sprints timeframe without being blocked for some external input. So the level of details needed in a story also depends to some extent on the relationship between the PO / SM and the eng team.
It is the product owners responsibility to maintain the product backlog in sufficient detail (at least the top few items) so that the dev will include them during sprint planning. In practice, I have seen this take the form of the product backlog grooming meetings ( 1 hr long / twice a week) that is attended by PO, SM , some dev team members, SMEs etc. The purpose of these meetings is to look at upcoming user stories identify external dependenies / process and collaboratively elaborate them in sufficient details to be included in the sprint backlog. This meeting is not part of the Scrum events so does not have to be there and can take some other form it needed.
In your specific case for example does your PO or Dev team have the authority to define the username / password requirements or are you part of a larger organization where the username /password is defined as part of corporate security policy that you will need to follow. Do you have to pass any kind of security assessment for the application ? I have had experience where once the scrum team was done with the implementation we were blocked by a corporate security assessment process for over 3 months.:). I dont think any process will help you in such case Agile or Waterfall.