Our strict Scrum implementation acknowledges two work units:
1) Product backlog items (PBIs): concise, finite, measurable goals with deliverables that are either Done or Not done based on a simple question "Did you <PBI title>?", defined and owned by the Product owner
2) Tasks: atomic, weighted (estimated) work units assignable to a single Scrum team member, defined and owned by the Scrum team
How long can these work units be?
1) PBIs must always be achievable within a Sprint's time (under one month) and Scrum team must never commit to a PBI without being sure they can complete it within the Sprint
2) Tasks should be as short as possible and a rule of thumb is for each Scrum team member to have at least one task completed each Sprint day (daily deliverables)
What happens when we have goals that cannot be achieved within one Sprint's time or when goals are abstract/broad enough to give teams much flexibility to have to first figure out how to achieve them? Enter Epic
An Epic is a Product backlog item "on steroids" with the following differences:
a) Epic is broad, abstract and cannot be always confirmed as Done or Not done based on a Did-you question
b) Epic is done when the client (Enterprise Product owner in our case) say it is done
c) Epic has no time limitation - it can be worked on for one week or for several months/sprints until the client need is fulfilled
d) Epic is owned and defined by Enterprise Product owner
e) Epic cannot have any Tasks directly defined under it, but instead it has individual measurable Product backlog items as means to accomplish it through one or more Sprints
How will we know that an Epic is really Done? When your client confirms that the needs have been fulfilled. The needs are usually to achieve a specific business objective / specific change in actionable metrics. See some examples next
Developers (Web developer team included)
Epics provide a good way for Enterprise Product owner to describe Production roadmap:
A) "Provide a new product to competitively enter the Azure data compare market" - concise enough to explain the need but broad enough to allow Product owner to figure out technical details and step-by-step PBI deliverables with the help of the Scrum team(s)
B) "Provide a new data restore product version to exceed comp performance" or "to achieve fully competitive state"
Marketing, SEO
A) "Increase leads by 50%"
B) "Establish company presence on a new major community network"
Operations
A) "Increase lead conversion by at least 10%"
B) "Make Scrum success rate efficiency 95% or higher"
SysAdmin
A) "Establish 3 levels of company data backup"
B) "Improve uptime of all TFS services to 99%"
Support
A) "Boost RECOs by 10%"
B) "Establish a new defensive support system to halve repetitive cases"
QA
A) "Implement new test cases management system"
B) "Fully automate testing of all products' command line functionality"
