One challenge of integrating designers and developers into poly-skilled teams is the management of design and code related tasks. Atomic has tried working with both integrated and non-integrated backlogs.
On the myGRcitypoints project, we opted for an integrated backlog approach.
The integrated backlog approach was very useful for:
- Designers and developers sharing responsibility on middle ground tasks like Information Architecture or CSS & HTML
- Interleaving design and code tasks to expose dependencies and potential future bottlenecks
- Having a single place to capture and manage the entire scope of the project
The above screen capture shows a portion of myGRCity Points integrated backlog.
We used a convention to identify tasks types:
- D: General Design (sometimes abstracted tiny visual design and markup tasks)
- C: General Code
- X: Information Architecture and Interaction Design
- M: CSS & HTML Markup
- V: Visual Design
You can see how we staggered individual profile design tasks ahead of code tasks. Keeping design tasks ahead of code tasks reduces scrap and rework effort. The team tried to subordinate themselves to working in a design first manner as much as possible.
The team decided who would work on what tasks depending on skill sets, strengths and dependencies. If we had a glut of V tasks, the coders would help give support in X & M tasks. If we were getting bottlenecked on C tasks, the team designer would do more work in X & M tasks.
Integrating a backlog with design and development tasks gives rise to other project management considerations about scope and velocity tracking. We maintained an integrated burn chart that included total team velocity and total backlog scope. We kept the burn chart integrated due to consistent team member allocation. Not all projects should take the same approach.
In the future, I’ll be posting more observations about benefits realized from the integrated backlog approach and related project management techniques.