The Team Backlog is owned by the Backlog Owner. For example, in the Scrum Framework, that would be the Product Owner. The Team Backlog contains a wish list of work items that the Backlog Owner and his or her Business Stakeholders would like to get implemented. How long it takes to implement each work item in the Backlog depends on the prioritization and complexity of each one. The Implementation Team will provide input on the complexity and dependencies, while the Backlog Owner will give input on the overall Business value. All of this will drive the overall prioritization of the Backlog. A Typical Team Backlog would contain the following work items:

  • User Stories – Functionality/Feature component that represents customer value and can be implemented within a sprint. Estimation for these stories will be in story points. The basic User Story is structured using functional descriptions of system behaviors. Most often the user drives them, i.e. they align with a usage scenario that a customer would follow in leveraging the application or system. Product Owners typically write User Stories. However, they can get help and input from the team as needed. If the story is technical or related to QA the team can write the story as well.
  • Technical Stories – Technology feature that is typically architecture, performance or back-end work that is not customer facing, but can also cover Technical Debt or the refactoring of related work as well. Estimation for these stories will be in story points. Technical User Stories primarily represent non-functional support of a system. For example, implementing back-end tables to support a new function, or extending an existing service layer. However, these stories may also address technical debt, technical analysis, design, or even architectural work. All of these are focused towards underlying support for base functional behavior. Technical Stories should be defined with the assistance from technical staff that understands the technical design and implications of the product stack.
  • Spikes – Research or prototyping work that is necessary before implementing a User Story. Estimation will be in story points. Spikes can be used for business clarification for a story, but it is important to not abuse Spikes. One rule of thumb is any type of research or analysis that is less than 2 days can be combined with the User or Technical Story.
  • Defects – Defects that are found on prior-working functionality is logged in the Backlog as a Defect or Bug. Estimation will be in story points. Defects found during a sprint for a User Story worked on during the Sprint will not be recorded in the Backlog, but can be documented in the comments section of the User Story.
  • Sub-tasks – Unit of work that is part of a User Story or equivalent Work Item. Estimation and tracking will be in hours and should range between 2-16 hours per Sub task. Sub-tasks can be development, QA, UX, etc. The sub tasks are all the work the team must complete to develop, test and accept the story as “Done”.
  • Non-Functional Requirements – Non-functional requirements are often called "quality attributes" of a system. They specify criteria that judge the operation of a system, rather than specific behaviors, for example:
  • Accessibility
  • Auditability and control
  • Availability (see service level agreement)
  • Backup
  • Capacity, current and forecast
  • Certification
  • Compatibility
  • Compliance
  • Configuration management
  • Cost
  • Dependency on other parties
  • Deployment
  • Documentation
  • Disaster recovery
  • Efficiency (resource consumption for given load)
  • Effectiveness (resulting performance in relation to effort)
  • Emotional factors (like fun or absorbing or has "Wow! Factor")
  • Environmental protection
  • Escrow
  • Exploitability
  • Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
  • Failure management
  • Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
  • Legal and licensing issues or patent-infringement-avoidability
  • Integrability (ability to integrate components)
  • Interoperability
  • Maintainability (e.g. Mean Time To Repair - MTTR)
  • Management
  • Modifiability
  • Network topology
  • Open source
  • Operability
  • Performance / response time (performance engineering)
  • Platform compatibility
  • Privacy (compliance to privacy laws)
  • Portability
  • Quality (e.g. faults discovered, faults delivered, fault removal efficacy)
  • Readability
  • Reliability (e.g. Mean Time Between/To Failures - MTBF/MTTF)
  • Reporting
  • Resilience
  • Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
  • Response time
  • Reusability
  • Robustness
  • Safety or Factor of safety
  • Scalability (horizontal, vertical)
  • Security (cyber and physical)
  • Software, tools, standards etc
  • Stability
  • Supportability
  • Testability
  • Throughput
  • Transparency
  • Usability (Human Factors) by target user community

It is important that the Backlog Owner and Implementation Team agree to a healthy allocation of work for each Iteration or on a weekly basis (if it is a Kanban Team). This will ensure less bottlenecks, resolving risks and dependencies sooner, preventing blockers, etc.

It is important the Product Owner prioritizes the work items in the Backlog. Some common approaches the Product Owner can take to prioritize are:

MoSCoW

  1. Prioritizes stories into four categories:
  • Must - A story that just has to be made. Release has to be postponed of all Must's aren’t done.
  • Should - An important and should be included. However, missing one or two isn’t going to prevent release.
  • Could - A nice-to-have feature that can have high value-added for the product.
  • Won’t (for now) - A feature that has been shifted out-of-scope for current release or otherwise removed.
  • M’s and S’s usually comprise into Minimum MarketableFeatures (MMF).
  • Just having Must’s done doesn’t necessarily make a market-worthy product.
  • A fast tool and suitable for large amount of stories.
  • Important to recognize the difference between Must’s and Should’s!
  • Can be made from technical or business point of view.
  • Comparing the differences between the two can be Enlightening.
  • When planning releases, a maximum of 70% of size should be Must’s.
  • If more, the statistical probability of not getting the release out starts increasing.

Kano Model (Defining Value by Desirability)

  • Uses Kano Model of Customer Satisfaction.
  • Uses a specific type of customer research query.
  • Categorizes features into three categories:
  • Threshold, or must-have, features.
  •  “Minimal acceptance criteria”.
  • Linear features.
  • “The more the better”.
  • Exciters and delighters.
  • Premium features.
  • Prioritization
  • Get all threshold features.
  • Complete as many linear features as you can afford.
  • A few exciters for premium and differentiation.

Mañana technique:

  • Mañana technique is a simple prioritization tool for filtering out items based on relevance.
  • Useful for narrowing down the amount of features under current evaluation.
  • At the start of the exercise, define the mañana threshold.
    • Items we need to consider in some way during the first two sprints.
    • Items those are relevant for the first beta release.
    • Items are placed into two piles:
    • "Now" - These items have relevance within the given threshold.
    • "Mañana"- These items can be safely put aside for now. 
    • Once divided, put the Mañana pile aside and focus on the items in the Now pile.
    • Can be run iteratively to identify different levels of Mañana.
    • E.g. first for release, then for the next two sprints; the first Mañana pile can be put aside until next release, the second one only for this workshop.

Once the Product Owner has prioritized and groomed the top Work Items, then they can go into Backlog Grooming with confidence. Work Items up for conversation such as User Stories must be groomed by the Product Owner prior to Backlog Grooming. This means, the Story must have:

    • Title.
    • Narrative.
    • Description.
    • Acceptance Criteria.
    • Initial priority.
    • Supporting lean documentation like Architecture, Technical, UI/UX specs.

Example:

Title

Planner enters new contact in address.

Narrative

As a Planner, I can enter a new contact in the address book so that I can call or email the person in the future.
I enter standard contact information in contact-entry screen (the fields are last name, first name, company, address, email, and phone.) I can either save the data, or discard it and return to what I was doing.

Acceptance Criteria
  • Tester can create a new contact, then enter and save all fields.
  • Application will not save entry unless first and last names have been provided.
  • Application prompts for new name on save, if first and last name combination already exists (match is not case-sensitive).
  • Lookup of saved entry gives read-only view of contact, showing fields previously saved.

This ceremony will then serve as an opportunity to facilitate the 3 Cs – Card, Conversation, and Confirmation, with the Implementation Team.