Skip to main content

Detailing requirements

Last post 01:14 pm August 28, 2012 by Charles Bradley
4 replies
09:21 am August 23, 2012

Hi,
This is Daniel R. from Brazil, I have been studing about Scrum and some doubts arose.
Could you help me?

My doubts:

If I already have a requirements list, then when could I start to spell it?

I´ve got to create a specific Sprint to detail that? Or should I start the analyses along the development?

How can my Product Owner be ahead of the developers?

Thank you.

Regards,
Daniel


09:53 am August 23, 2012

Hi Daniel,
Once you have your initial set of requirements, I have found it useful to have a workshop with the Product Owner and the Development Team to groom the backlog in to a reasonable state.You need to have a compelling vision to focus the team on what you are aiming to deliver - it helps bring everyone together to build a coherent product.
Ensure that the INVEST (Independant, Negotiable, Valuable, Estimateable, Small, Testable) are met, making it clearer what is required to get that PBI to Done..
It is very helpful to have a couple of Sprints worth of Product Backlog Items (PBIs) ready to be taken in to the next Sprint. This gives flexibility in Sprint Planning.
After the initial workshop, you should spend around 10% of your Sprint capacity for the Product Owner working with the Development Team to maintain the Product Backlog in a healthy state. This will be adding new PBIs, reordering, breaking down big PBIs in to smaller PBIs, estimating etc.
The Product Owner will be adding and reviewing changes before any formal sessions. They also need to be working with any stakeholders and customers to reflect their desires to make sure that the most valuable (to the business and the customer) are at the top of the backlog and get done first.
They will need to set aside time on top of their other duties to focus on this, as it is a critical aspect to getting the best possible product released.

Regards
Simon


01:08 am August 24, 2012

Daniel,

If I've understood your question correctly...

I generally coach teams to take a couple of days before starting their first sprint to:
a) Get the sprint to start on the day of the week they initially want, and
b) Bulid up and groom the product backlog, and
c) Do a retrospective. You heard it -- a retro before you begin. I find it very valuable to record the results of that retro and then refer back that a few sprints later after some improvements have been made. Helps to see how far you've come.

As to how to get the PO ahead of your dev team, I recommend weekly, full Scrum Team backlog grooming. I have a series of articles on my web site that detail the ins and outs Backlog Grooming.

Good to start here:
http://www.scrumcrazy.com/What+does+Product+Backlog+Grooming+Look+Like%…


04:25 am August 28, 2012

Thanks,
Charles Bradley and Simon.

Hugs,
Daniel


01:14 pm August 28, 2012

You're welcome. I'm happy to help! Feel free to contact me off-line for your requirements questions. You can contact me by putting Charles before @ScrumCrazy.com


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.