Implementing Scrum in a Digital Agency
Hi,
I am currently trying to document a migration to scrum for a digital agency. There are of course the usual agency problems of many small projects for different clients. I think I have things set out pretty well but would welcome any feedback on my proposed structure.
1. Two scrum teams working to a two week sprint time-box.
2. The sprint starts will be staggered by a week to allow for rush jobs to never be more than 5 days from entering a sprint.
3. The teams will be fed by a single backlog which will be prioritized by the agency's client services team and refined by two backlog grooming sessions (one per team) a week.
4. A member of the client services team will act as product owner on each team.
Thanks,
Tony
> 3. The teams will be fed by a single backlog which will be prioritized
> by the agency's client services team and refined by two backlog grooming
> sessions (one per team) a week.
Will these refinement/grooming sessions include estimating the size of the PBI's? Remember that in Scrum, each team must be responsible for its own estimates regarding the work that it actually does.
Good point Ian, that would be a difficult one to manage so I will have to change it to two separate backlogs.
The number of product backlogs should reflect the number of products you actually have. Each of those products (and the corresponding backlogs) should have a clear Product Owner. In other words, organizing a Product Backlog shouldn't be a decision that is driven by team delivery capabilities. The driver should be one of business need.
There can be situations where multiple products need to be serviced by a Scrum Team. This is fairly common in agency work and also in big companies where multiple assets require maintenance by operational support. In these situations, it may be viable to combine the requirements for multiple products into a single Product Backlog as long as a single Product Owner can be found...and entrusted...to represent them.
If you have multiple teams drawing from a single Product Backlog, it may be reasonable for them to conduct joint backlog refinement sessions, where they estimate jointly using the same terms of reference.
> organizing a Product Backlog shouldn't be a decision that is driven by team delivery capabilities
I ought to have said *creating* a Product Backlog shouldn't be a decision that is driven by team delivery capabilities. The way those backlogs are organized after creation can be informed to some extent by a team's abilities, projections, and constraints, even though the Product Owner remains ultimately accountable.