My organization does web projects and employs a handful of disciplines like backend dev, frontend, BA, UX, graphic design, QA. We’ve been pushing to have tasks for every discipline in our sprints with explicit dependencies (Can’t build a page without comps, can’t do comps without wires, etc). I’ve heard some other organizations say that scrum is only for dev tasks. Are we barking up the wrong tree? And, if not, are there any good tools for doing capacity planning when only certain resources can do certain tasks?
1
Maybe.
I’ve run agile with everything before. Some things (graphic design, UX, BA) are better split into different teams, and to some degree different user stories. Then the hard dependency can be resolved before you take the dependent story off the backlog.
For things like documentation or QA, these are things that need to be really done with development. They’re not so much hard dependencies as related tasks that should all be completed before something can be “done”.
This is a tricky question. The issue is that you require some of the artifacts (like you mentioned comps, wire frames) as input for the other tasks (development). Based on this, I would say that estimating the development tasks is hard to impossibly without this input, which is obviously something you want to avoid.
I can see two approaches to help with this:
Separate Stories
Treat the tasks to come up with the input required for development as separate stories, e.g. have a story for “Account Screen UI” and a second one for “Account Screen Dev”, with a dependency between each other. Then the UI team can work on the first story in Sprint X, and the Dev team can work on the second story in Sprint X+n, given that the UI story is done.
You might run into issues with this due to the dependency, e.g. if it’s not clear that there is a dependency.
UI work outside of the Sprint
In this approach, work on the UI tasks outside of the development Sprint. You still treat the UI work as a dependency for development, but the UI team doesn’t work as part of the Dev team and not within the frame of the same Sprint.
This is the way we’re currently working, since we have some of the same dependencies. We created a Definition of Ready, which defines the information that needs to be available for a story to be deemed ready, i.e. it can be moved to development. One part in this Definition of Ready is that all UI stories have mockups, screenshots or wireframes attached to them. As part of the Story Grooming, we work with the UI team to go through the stories, and they create mockups etc. Once these are there and the story has acceptance criteria, it can be estimated (Planning Poker). Once that is done, it’s ready.
In this model, the grooming or UI work can be done in an agile manner as well, where the grooming and/or UI team is using an agile process. It could be Scrum, or it could also be Kanban, which might be better suited for this kind of work.
6
I would keep your teams cross-discipline. If one team is too big, I would split the project into separate Scrum teams with each team being cross-disciplined. (At a push, people can split their efforts across two or more teams if necessary; you just need to take this into account when estimating against velocity.) Splitting teams and stories into design/prototyping/dev etc is counter-productive, I think, for reasons I gave in the comment to @nwinkler: you should only ever create stories that deliver value to the customer.
Kanban or Scrumban are good approaches that may help your thinking where dependencies are concerned. If you judiciously control your WIP limits, they would let you create wireframes before the dev takes place, without reducing the total turnaround time for a feature. I have found this especially useful if people ever need to wear different “hats”: e.g. if the “test” column reaches its WIP limit, a BA or dev could put on their tester hat for the day.