Improve requirements and backlog management

Owned by Katsiaryna_Subach
Last updated: Jan 17, 2022 by Aleksandr Bogush
3 min read

  1. Split features into smaller parts (no more than 5SP, or 1 day length) 

  2. Each "ready for development" User Story should meet Definition of Ready following INVEST principles

  3. Reflect functional in a User Story and NFR - in an Enabler

  4. Apply best practices of splitting features based on data boundaries (data sets, values), operational boundaries (CRUD operations), removing cross-cutting corners (security, logging, error handling), separating functional and non-functional aspects), etc

  5. Ensure to apply slicing model of user stories creation and implementation, i.e. they should not be split horizontally by layers like frontend and backend, but rather by small pieces of functionality

  6. Apply requirements gathering techniques in order to make sure there are enough details to get estimated and "ready for development" backlog: surveys, interviews, brainstorming, observation, prototyping, audit, etc

  7. Make sure to keep properly prioritized backlog by PO, track and analyze internal and external factors that can potentially impact business strategy and priorities to be able to control it and facilitate re-prioritization with PO

  8. Keep focus on backlog prepared for the nearest sprints and support team during sprint execution from requirements perspective. All other new requests or ideas should be gathered and elaborated, however postponed for deeper analysis and refinement from development perspective until become in following priority

  9. Reassess quality of backlog refinement sessions, the same is for team’s engagement in analyzing requirements and challenging BA/PO with questions. I.e. edge cases should be discovered beforehand to eliminate risk of finding them out during implementation

  10. Invite right subject matter experts to backlog refinement sessions, hold this event at regular intervals 

  11. Introduce User Story Definition of Done or/and Success Criteria

  12. Create or enhance User Story template 

  13. Apply BDD (behavior-driven development) approach in requirements management 

  14. Revisit demand intake flow and/or with requirements management process, i.e. make sure that all business ideas are specified in a correct way, and confirmed with the client to be on the same page. Describe exact steps, activities in each step/phase, actors or owners in this process

  15. Make sure that requirements are validated and accepted by the relevant stakeholders 

EngX recommendations

  • Track all your tasks in a single tracking system (for example, Jira), and have the only single backlog for given (sub)team. Document the process (for example - Jira Workflow, How to create Story, How to create bug) and let your stakeholders know the process. If somebody does not follow the process - share the link to the process and create a task according to the process in behalf of that person.

  • If there are multiple channels to accept tasks (for example, Skype, Slack, Teams, e-mails) - automate the process of the task intake to create task in single tracking system and report task # to requester

  • Make sure your backlog is prioritized by single person (PO in most cases) or at least clear rules are defined. For example - production bugs have highest priority, then bugs from sprint, then stories which are in sprint etc.

  • Use the same backlog for improvements and process changes if you don't have separate project/team for such activities

  • Add new tasks to that backlog, initially all requirements could be high-level, to spend less time possible (responsible - PO)

  • Regularly review backlog and remove redundant tasks, re-prioritize backlog according to business needs (responsible - PO, task removing - PO+BA+Team)

  • Follow Scrum principle as for level of details in the given task - as higher the task in queue as more detailed requirements should be in the task (responsible - PO + BA)

  • Keep backlog healthy - number of tasks ready for development (all requirements are in place, clarified with the team, no major questions) should be enough to run them next 2-3 sprints

  • If there is long-time project with pretty long backlog (3+ months), there is strong recommendation to do not start development as soon as possible with stories not passed DoR, but spend a time for spikes/grooming/clarifications to make sure backlog is healthy to fully fit at least one sprint

  • Use MVP approach (Minimal Viable product) whenever possible, especially for long projects

  • Release MVP to production if business see the value and no risks to affect brand

  • Conduct discovery sessions with customer in order to identify significant NFRs:

    • Performance and scalability. How fast does the system return results? How much will this performance change with higher workloads?

    • Portability and compatibility. Which hardware, operating systems, browsers, and their versions does the software run on? Does it conflict with other applications and processes within these environments?

    • Reliability, availability, maintainability. How often does the system experience critical failures? and how much time is it available to users against downtimes?

    • Security. How are the system and its data protected against attacks?

    • Localization. Does the system match local specifics?

    • Usability. How easy is it for a customer to use the system?

    • Accessibility, Internalization, etc


Useful materials

External:

Internal: