I'm looking for some help finding resources on sprint planning specifically for agencies, namely a web design and development firm focusing primarily on web apps. So a typical project would be a client signing on for a website, let's say. We go through research, UX/UI, design, development, deployment, and—in some instances—ongoing maintenance. I should also clarify that the agency is relatively small with 9 members in total.
Resources seem plentiful for in-house software teams, but not so much for agencies. Specifically, planning sprints for cross-functional teams working on multiple projects at a time for several clients.
The problems/pain points I'm looking to solve through this approach are:
- Filling in "down time" on a project—e.g. while waiting on design approval on project A, the designer should be working on X, Y, and Z on project B—in such away that blockers are accounted for across the team. Not just filling in the time with random tasks from the backlog.
- Better cross-team communication on project statuses, when and how blockers are resolved, when work needs to move from one team to the next. People are not accountable to anyone else because they don't really understand how their work on project A might affect how someone else is able to do their work on that same project or even how it may impact a different project.
- Better understand our capacity for new work.
Right now things are basically set up as an endless list of tasks across several kan-ban boards. Tasks get done when the milestone is due. This is all well and good, but it means project can sit and wait until the next milestone is due or that another person is not aware that their work is no longer blocked.
Any help would be tremendously appreciated.
Also, would be looking for anything detailing accounting for "emergencies" or "rush jobs" from clients interfering with said sprint.
👆This is less important to me, as scopes are pretty solidly set in the contracts we sign with our clients. However occasionally a server will go down or a bug in production will pop up, these are pretty unavoidable across any software team, I'd imagine.