The Designer in Production
The goal of production is to deliver tasks as quickly and efficiently as possible, and to prioritize them across sprints so each sprint is well spent. The designer’s role shifts to:
- Making task-level design decisions, many of them driven by technical limits, and recording them in acceptance criteria during refinement and planning
- Knowing when to escalate a decision for discussion and when to just make the call
- Backbriefing stakeholders on those decisions during sprint reviews
Keep Task Scope Tight
Poorly defined tasks lead to waste and chaos. Beyond writing good tasks, use definitions of ready and done, timebox hard-to-bound work, abort tasks that get out of control, and hold quick daily reviews of work in progress.
Swarm
When one person’s task stalls, it is usually better for the team to help move it to done than to start something new. Form a small sub-team, name a coordinator, and let them self-organize.
Slice the Work
Plan delivery in increments: a minimum viable product (MVP), then improved versions. Slice horizontally (one layer of the system across many features) or vertically (one feature through every layer) depending on what gets useful software in front of users soonest.
Triage Bugs
- Input: make it cheap for anyone to report a bug, even in rough form.
- Filter: someone removes duplicates and mis-reports.
- Triage: a small group, for example designer, QA and product owner, sets priority and next steps.
- Report: QA turns bugs into detailed reports in the backlog.
- Prioritize: the product owner and team weigh bugs against the rest of the backlog.
Track Real Progress
If you can’t answer “when will it be done?”, you aren’t managing the project. “Time spent divided by the original estimate” is not percent complete. Instead, use several measures and look for agreement between them:
- Current (not original) estimate versus time spent
- Requirements passing validation versus total
- Features complete versus total
- Use cases passing their quality target versus total
- Open bugs at each priority versus the quality target
Use relative sizes, then forecast with historical velocity. For example, four requirements done in the last two months is a velocity of two a month. And remember: releasing always takes longer than it looks once development seems complete.
Run Regular Project Reviews
The goal of a project review is to judge the project’s health and decide what it needs. At a minimum, cover:
- Requirements and budget burn: requirements done, past pre-production and total; budget days spent and remaining; the current trend line against the ideal.
- Artifact status: in pre-production, requirements analysis, use cases, UX designs, technical architecture, interface designs, QA plan and licensing. Toward release, test cases, automated tests, validation results, documentation, a UX review, known issues, release notes and marketing materials.
- External coordination: release planning, work shared with other teams, and handover or closeout.
- Milestones: progress toward the next one, and whether future dates and scope need to change.