Contoso Payments: Dependency Visibility Without Meeting Overload
Contoso Payments has five teams (4-9 engineers) using Azure Boards for planning and GitHub for code. Four teams run two-week sprints; the platform team runs three-week sprints. Portfolio managers meet monthly and receive a status deck that takes six engineer-hours a week to assemble. Cross-team dependencies live in a shared spreadsheet because nobody trusts the board. After default notifications were enabled, engineers receive roughly 1,200 emails a week; about a third have muted everything, and last sprint a blocked dependency sat unnoticed for four days. Area paths are flat, one per team, and almost every work item is a User Story with no Features above them. Leadership wants predictable monthly reporting and same-week escalation of blockers without adding meetings.
1. Propose a work item and area path model that supports cross-team dependency tracking and portfolio rollup. What would you change, and what are the tradeoffs?
Read the worked answer
Introduce the Epic > Feature > User Story/Bug hierarchy. Features become the portfolio unit: owned by a product manager, sized to a quarter, and stable enough to report on. User Stories stay team-owned and sprint-sized. Keep one area path per team but nest each under a single Payments area so queries and permissions can roll up at portfolio level and filter at team level.
Mismatched cadences are handled with iteration paths, not area paths - shared iteration nodes let sprint comparisons work even when team calendars differ.
Model dependencies with Predecessor/Successor links, not free text in a description. Linked dependencies are queryable, visible in Delivery Plans, and can drive escalation. Tradeoff: hierarchy adds grooming overhead and only works if Features are genuinely maintained; a flat User Story list is cheaper but cannot roll up or show dependencies. Resist one area per sprint or per initiative - it fragments queries and bakes reporting debt into the structure.
2. Design the notification and escalation approach so blockers surface within hours without recreating email overload.
Read the worked answer
Azure DevOps notifications are per-user subscriptions, so there is no global fix - treat this as channel design, not a setting.
- Keep individual subscriptions to the minimum that needs a person: assigned to me, @mention, review requested. Everything else moves to team subscriptions scoped by area path.
- Route state-change noise to a Teams channel via a service hook, filtered to the events that matter: work item set to Blocked, build failed on main, PR with required reviewer pending over 24h.
- Add a scheduled query (Blocked items older than 24 hours, or with a past-due Successor) that posts daily to the team channel with a named rotating triage owner.
Tradeoffs: channel posts are visible but easy to skim past, so an owner is mandatory; email is more intrusive but is exactly what caused mass muting. A muted engineer is worse than a quiet one. Also avoid notification-per-transition - batch by day and escalate only on age.
3. Choose the mechanism for the monthly portfolio review and justify it against the alternatives.
Read the worked answer
Use Analytics/OData with Power BI for the monthly numbers, plus Delivery Plans for the date conversation.
Analytics gives a semantic model over work item history, supports scheduled refresh, and filters by area and iteration, so the deck becomes a fixed report nobody rebuilds. Six engineer-hours a week disappears after a one-time modelling cost.
Delivery Plans answers a different question - when will Feature X land, and what does it depend on - and is the better artifact for the live stakeholder conversation. It is a calendar, not a KPI report, so do not try to make it one.
Tradeoffs: Analytics has minutes-to-an-hour latency, so intraday decisions still belong on the board; Power BI needs a licence and a named owner for the dataset or it rots. Custom REST-API reporting is only justified for data Analytics cannot expose. The wrong answer is a hand-built deck, because the second month always diverges from the first.