Skip to main content

How to include big meta-level requests in a product backlog

Last post 07:54 pm January 30, 2018 by Chris Field
4 replies
Anonymous
03:35 pm January 25, 2018

Hello everybody,

I became aware about Scrum and I am considering to implement it for a project. I read the scrum guide and lots of scrum related articles. However, I still can't imagine how I can deal with requests to a project which are on a more top level than a usual feature.

All the examples I saw so far are about small features and needs. E.g. user stories like "as a customer I want to see a summary before I place my order to ...". This is an easy item. One could pick it during a sprint and implement such an view.

But how does a request like "everything should be in line with the corporate design". Maybe it is not the best example but hopefully it is good enough to make my point clear. This request is not a single feature or bug which can be done during a sprint. It is more like a meta level request that has to be considered during the hole project.

How can one deal with this high level requirements when the only source for tasks is the product backlog solely?

 


10:03 pm January 25, 2018

Must the meta-level concern be addressed for each product increment to be considered "done" and of release-quality?


Anonymous
06:40 am January 26, 2018

Maybe.

In terms of the example with CD one could think of a last task where some space holders are replaced with fitting material. But this is of course only an example. I'm pretty sure every project has this kind of requirements. Already the description of the project itself is a really big thing.

Imagine the Project is to design a car. Maybe a SUV. If you brake down everything to the smallest features how do you keep track not ending up with something like a new beatle?


09:35 pm January 26, 2018

Why not organize the product backlog at different levels of abstraction such as user stories and epics, or link items by theme, or perhaps order items in terms of future release goals? Each Product Backlog Item should have a description, value, order, and an estimate, but that is a minimum prescription. A Product Owner can include other attributes or organizing constructs in the backlog, and use these to build a product plan.

If any product requirements or quality considerations must apply to each increment delivered, then it might be appropriate for the Development Team to address those concerns in their Definition of Done.


03:46 pm January 30, 2018

For cases like the example above, "everything should be in line with the corporate design", it seems like essentially non-functional requirements, so I also think it make sense to incorporate those into the Definition of Done as Ian suggested above. This could be consistent with a corporate style guide, CSS, etc.

For the beetle/SUV situation, I believe that a DoD for designing a 7 seat vehicle would stop you from building a subcompact. Or adding an engine not capable of sufficient power. Does this seem the correct application of Scrum?

With respect to 'meta' requirements a bit more generally, what would be the right way to address this situation where decomposing the style guide into a useful DoD could require a several weeks and a cross functional team? For a new-to-Scrum organization, could it make sense for a DoD to be produced in a sprint where the Dev team is a mix of developers, marketing, UI/UX, etc? In this case the 'useable increment' is an initial DoD, to be refined in subsequent sprints, which is sufficiently robust to allow delivering products 'in line with the corporate design'.

 

 

 


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.