Skip to main content

Implementing Scrum in a Digital Agency

Last post 12:00 pm January 8, 2015 by Ian Mitchell
4 replies
07:23 am January 8, 2015

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


07:52 am January 8, 2015

> 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.


10:47 am January 8, 2015

Good point Ian, that would be a difficult one to manage so I will have to change it to two separate backlogs.


11:48 am January 8, 2015

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.


12:00 pm January 8, 2015

> 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.


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.