How to include big meta-level requests in a product backlog
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?
Must the meta-level concern be addressed for each product increment to be considered "done" and of release-quality?
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?
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.
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'.