Planning
Planning
There are three Quantified Task measures related to planning. Much of the planning work is typically done up front by the Product Owner, Business Analyst, Product Strategist, and/or Stakeholders. Developers are involved in defining Priority as part of sprint planning.
Impact
Impact is the importance of a Task to the Solution as a whole, with an emphasis on the effect on users. It is used to keep track of a Task’s overall criticality throughout release cycles.
This measure is defined by the Product Owner. Developers should never change Impact themselves without the involvement of the Product Owner. That said, the Product Owner should be aware that Impact is intentionally distinct from Gravity and Priority (defined later).
Impact is defined by the effect that not completing the Task would have on the Solution’s goals. There are a few criteria for each, as seen below:
i5: Massive.
i4: Significant.
i3: Major.
i2: Minor.
i1: Slight.
iT: Triage. Impact not yet assessed.
As a rule, if everything is important, nothing is important! Applying the Rule of Pareto, i5 and i4 Tasks should account for only approximately 20% of the backlog. A good way to think about this is to imagine a minimum viable product (MVP), which contains only i5 features. An MVP is often not going to be particularly fast, easy to use, or aesthetically pleasing; it is only going to perform its essential functions in the most Spartan manner possible.
Impact Analysis
Proper use of Impact involves several factors. The Product Owner should generally take the lead in this analysis work, although it may be delegated to a Business Analyst.
Determining User Groups
When analyzing Impact with Stakeholders, the Product Owner must first have identified and documented the intended user groups for the Solution.
primary user group — a user group for whom the Solution is being designed. If there is a stakeholder matrix from a stakeholder analysis, this is “high-impact” group.
secondary user group — a user group which is supported, but for whom the Solution is not primarily being designed for.
Epic Impact Analysis
Once the Product Owner has identified the user groups, use cases can be determined and considered. These should map to Epics (in Scrum), not to specific user stories.
Impact should be scored on Epics to record their importance to the Solution overall. Although your issue tracker will likely just use the normal Impact field, we’ll refer to this score herein as “Epic Impact”, or “Ei”.
Ei5: Massive. Essential use case. If omitted, the Solution is considered inviable. Security and stability are always considered essential use cases.
Ei4: Significant. Common use case. Expected to be used routinely by at least one primary user group.
Ei3: Major. Expected to be used routinely by at least one secondary user group, or occasionally by a primary user group.
Ei2: Minor. Expected to be used only occasionally by a secondary user group.
Ei1: Slight. Optional use case — omission would have no effect on Solution viability or user experience. (Bells, whistles, and gongs.)
Impact Analysis on Tasks
When considering a Task, consider its effect on its associated Epic (use case). There are four levels of impact to a user case, represented by the acrostic BIDS:
blocks (B) — the use case is inviable; high security/stability risk.
impedes (I) — the use case is difficult to use; medium security/stability risk.
degrades (D) — the use case works without it, but with some noticeable inconvenience to the user; minor security/stability risk.
scuffs (S) — effects on the use case are unlikely to be noticeable to the user, except in edge case scenarios; trivial security/stability risk.
These correlate to the Epic Impact [Ei] as follows:
| | i5 | i4 | i3 | i2 | i1 | <-- Task Impact
| Ei5 | B | I | D | S | |
| Ei4 | | B | I | D | S |
| Ei3 | | | B | I | D/S |
| Ei2 | | | | B | I/D/S |
| Ei1 | | | | | B/I/D/S |
^
Epic ImpactGravity
Gravity is the importance of a Task in relation to a Release. It is useful for defining which features belong in each iteration of a Solution, and should be revised with each Release.
Gravity is normally defined in collaboration between the Product Owner and Developers. Gravity is influenced by Impact, and Priority (defined later) is often influenced by Gravity. What’s further, Gravity should never be set until Impact has been defined!
Gravity maps to MoSCoW Prioritization (more specifically, the modified MoSCoWW system.)
g5. Critical. Must be completed, or else the Release cannot ship.
g4. Significant. Should be completed. Omit from release if desperate. These are usually functional requirements, especially those that directly improve on g5 Tasks.
g3: Major. Could be completed. Non-essential, but candidate for inclusion in release if time permits. If omitted, becomes candidate for g5 in next release.
g2: Minor. Would complete given extra time, but is not slated for current release. May be g5 or g4 in next release.
g1: Trivial. Won’t complete. “Nice-to-have” Tasks that take a back seat to all higher-Gravity Tasks. There must still be reasonable certainty these Tasks will be included in a release someday.
gT: Triage: Task’s Gravity or inclusion in a release has not yet determined.
As with Impact, the Rule of Pareto applies here; g5 and g4 Tasks should only comprise about 20% of the backlog. It is the Product Owner’s duty to ensure the g5 and g4 lists are streamlined! Failure to do so will impair the Developers in setting priorities and planning sprints.
Epic Gravity
Just as Epics have an Impact score that represents their importance to the Solution, they also can have a Gravity score that corresponds to their inclusion in a Release. Epic Gravity [Eg] has the same possible scores as Gravity.
Priority
Priority defines how soon the Task needs to be completed, particularly in relation to a Sprint. A Task must have an Impact and Gravity before it can be given a Priority, to ensure work is selected based on Stakeholder needs and Solution goals.
Priority largely maps to Kanban columns:
p5: Emergency. Reserved for escalating a Task above all other priorities; “drop everything and do this now!”
p4: Now. Currently being worked on. Similar to Jira’s “In Progress”.
p3: Next. Should be completed in the current sprint. Developers should select Tasks to work on which have this Priority level. Similar to Jira’s “Selected For Development”.
p2: Later. Will likely be included in next sprint. May be pulled into the current sprint if time permits.
p1: Eventual. Not currently planned for the current or next sprint.
p0: Backlog. Not currently planned for any sprint. (Optional! This option may be useful for some issue tracker setups.)
pT: Triage. Not yet prioritized.
Priority should be adjusted on Tasks during sprint planning, and Tasks will increase in Priority as they are worked on. Priority must always represent the current plan of the Developers.
About Emergencies
A Stakeholder may request that a Task be marked as p5: Emergency, but it is ultimately up to the Product Owner to field and evaluate these requests. Remember: if everything is an emergency, nothing is an emergency.
Product Owners must be prepared to push back on such requests, especially if clients or other Stakeholders have an “emergency mentality”. An effective way to do this is to require a description of consequences if the Task is not completed immediately. Additionally, one can require the requester to identify at least one pending g5 (or g4, if no g5 exists) that may be cut from the sprint to accommodate the emergency request. With the latter technique, the Product Owner should only allow the primary Stakeholder to make that call, lest they get caught in a proxy war between Stakeholders over conflicting priorities.
See also, Rule of Emergencies.