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
-
1I would certainly include all relevant tasks. If the project cannot be finished without graphics, then ignoring the graphics folk in your planning isn't likely to be helpful.– Dan PichelmanMar 25, 2013 at 17:25
Add a comment
|
3 Answers
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".
answered Mar 25, 2013 at 17:32
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.
-
Separating stories into "Account Screen UI" and "Account Screen Dev" strikes me as a very bad idea. These aren't stories - they are tasks that are part of a story, but the story is either delivered or it isn't. A story delivers business value and what value to the customer is developing the wireframe? None at all. If you separate stories like this it makes it very difficult to prioritize them in order of business value since, as well as the issues of dependency that you mentioned, you simply cannot evaluate the value to the business of a task.– TimApr 4, 2013 at 9:01
-
I completely agree. It's an option, but it might not be a good one, due to the dependencies between these stories and the arguments you mentioned. Like I said in my post, the second approach is what we're using, where we treat the UI work as required input for the story to be "ready".– nwinklerApr 4, 2013 at 9:06
-
@nwinker I've worked with your second approach in the past. The problem I found was that there was a large backlog of pre-requisite work being done that was either wasted if the story was changed or never accepted, or created a pressure to accept a story because this work had been done. Does this happen with you? Like you say, Kanban might be better suited, and the more I've worked with it, the more I like it.– TimApr 4, 2013 at 9:20
-
We've had some of this at the beginning, but we've found that it helps if we move the Grooming and UI work as close as possible to the Sprint where it should be implemented. The main item for me is that the preparatory work (like mockups or wire frames) has to be done before development starts to estimate the story, since we've seen all kinds of surprises if we don't do that. We've had stories that looked really simple when estimated, but then we received a mockup that was really complex. Having the UI work done as a prerequisite helped us resolve this issue.– nwinklerApr 4, 2013 at 9:26
-
1Design stories definitely have a end product. A comp or wire. We avoid having mixed discipline stories since the chances of ux, design and dev happening in one sprint is nil.– jiggyApr 4, 2013 at 13:01
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.
