Project Management Central

Please login or join to subscribe to this thread

Practice Areas: Agile
How do you deal with a poorly defined backlog?
Network:2092



OK, Agile experts, perhaps you can help me out. How do you (as a team member) deal with poorly defined requirements in the backlog? I get that Agile is supposed to allow for some flexibility, but when you have two projects with overlapping but vague requirements, one team, one Scrum Master, one client, what's your tip for bringing it all together? At the moment there is a lot of duplicated effort and having to do twice as much work because the process is not efficient and the work isn't clearly defined. Thanks in advance for your tips!
Sort By:
Page: 1 2 next>
Network:173



Whatever may be the project management methodologies , need to have clarity on the requirement/scope to make the project success.

In agile should have acceptance criteria/definition done should be clearly mentioned for the team to pick the item into sprint/iteration. It is product owner responsibility to provide this information and scrum master will need to follow up or facilitate this

In each iteration/sprint 10% should be allocated to groom backlog and in iteration/sprint planning product owner should provide clarity on the requirements to team

1. Backlog grooming session
2. Iteration/sprint planning meeting

requirements should be caputured/documented in a template with details, Examples below
1. Problem Statement/Business case
2. What changes needs to be done in product/services
3. Impacted areas or coverage
4. What is not covered
5. Definition of done
...
1 reply by Renee Robinson
Apr 18, 2017 12:10 PM
Renee Robinson
...
Very good explanation of the methodology.
Network:126



Elizabeth, I assume there's one product owner? That person should work with the client and refine the backlog(s). It's ok if everything isn't clearly defined at the beginning; your client should have a more clear vision as you progress.

Also, when you say one client, is that one person? If there are multiple people coming from the same organizational client, that could explain some of the duplicated effort. Just as your PO should be the lone voice to the client, they should appoint a lone voice to you. Minimizing the decision-makers should reduce some of the duplication.

Good luck.
Network:1465



A grooming session with all of the agile team members should take place as soon as possible. In addition, these grooming sessions need to occur more frequently.
Network:179



I am assuming there is an overarching Project Management Plan with a scope statement for these Projects.

They should clearly outline the scopes of the two projects, the dependencies between the two projects in terms of similar requirements and also the dependency/constraint of there being the same Scrum Master, client and team.

The Issue Register should also highlight the risk of running two projects with a similar set of requirements where there could be a duplication of effort.

The main questions are - Is there a compelling reason why these are separate projects and not under the same umbrella? Is there an opportunity to get these under the one Project so the duplication of work is avoided?

The Business Analysts of the two projects are the key resources who need to nail down the requirements and make sure each requirement is testable and unambiguous.

I can clearly see the need for you to highlight this to the management and try and make this a one project with one scope, one product backlog and one team, with one scrum master and one focus with more clarity in requirements.
Network:2092



Thanks, everyone. These are really helpful replies.
Network:414



Does your team have a clearly defined and agreed upon definition of ready? The User Story is a conversation starter, but does not include everything the developers need to know to start work. Having a Definition of Ready establishes criteria that must be met before a story can be added to a Sprint. Just be careful that you don't go overboard - you could end up with something that looks more like waterfall - big design up front.
Network:286



One of the things my team struggled with is the actual capture of the items listed above:
1. Problem Statement/Business case
2. What changes needs to be done in product/services
3. Impacted areas or coverage
4. What is not covered
5. Definition of done

We have handled it a couple different ways - 1) each team member is responsible to capture and 2) scrum master captures these answers as part of the backlog grooming session. #2 works better for our team because we agree together on all of these items while defining the backlog together.
Network:44



I believe it's the Product Owner's responsibility to manage the product backlog and plan the iterations with the team based on their capacity/velocity and the project priorities.

How to deal with poorly defined requirements in the backlog
The PO has to be informed about this situation. As most of suggestions made, grooming sessions could be effective. There seems to be a disconnect between the PO and the remaining team. PO along with the rest of the team has to be on the same page as how the backlog containing the user stories are written and understood.
Network:254



Mar 30, 2017 7:17 AM
Replying to S Rajasekar
...
Whatever may be the project management methodologies , need to have clarity on the requirement/scope to make the project success.

In agile should have acceptance criteria/definition done should be clearly mentioned for the team to pick the item into sprint/iteration. It is product owner responsibility to provide this information and scrum master will need to follow up or facilitate this

In each iteration/sprint 10% should be allocated to groom backlog and in iteration/sprint planning product owner should provide clarity on the requirements to team

1. Backlog grooming session
2. Iteration/sprint planning meeting

requirements should be caputured/documented in a template with details, Examples below
1. Problem Statement/Business case
2. What changes needs to be done in product/services
3. Impacted areas or coverage
4. What is not covered
5. Definition of done
Very good explanation of the methodology.
Network:1667



Lots of great tips and kudos to you for recognizing you had a problem and working to rectify it. The only other thing I would add, what is the Product Owners power in this? Typically when you have a strong Product Owner and solid Business Analyst, you can confidently work through those vague requirements and make them solid. If they are just figureheads and a non-technical resource is driving this, you might have problems.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"If a man does only what is required of him, he is a slave. If a man does more than is required of him, he is a free man."

- Chinese Proverb

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events