Release backlog is the backlog of all features that are supposed to be done in order to release the product, whereas sprint backlog is the list of all tasks planned for the following sprint. Sprint backlog contains only those tasks which are required to be completed within one sprint.
Sprint backlog appears at the beginning of each sprint and contains all tasks which the team should accomplish during this time frame. At the end of this timeframe, these items should be either completed or at least partially completed so they can be moved to release the backlog. A more important question to ask is who owns the sprint backlog.
Release backlog might contain thousands of features/issues which will not necessarily appear in the sprint backlog at any point during development – someone decided that they can wait until later (perhaps because other features depend on them). The release milestone also defines the deadline for completing all items in the release backlog.
The release will be considered complete when all items in the release backlog are fully developed and every item finished during that time frame shows a green “ready” and “completed” status. Sprint-based sprint (mini-milestone) should meet its goal, hence enabling you to determine if the product is moving forward towards the desired direction.
Mini-milestones could include features that need fixing or refactoring, but they can also contain other types of tasks such as: improving documentation, testing, training employees on new features/fixes/system changes, and so on.
Each sprint has a duration of up to 4 weeks – 1 month where the development team should spend their time working exclusively on items from the sprint backlog. Some shorter Sprints might enable better forecasting accuracy, while longer ones might allow better planning.
As far as I know, there is no predefined best practice regarding Sprint duration. The challenge which you are facing right now is to figure out the right balance between flexibility and predictability. Hence it is very likely that you will have to experiment with different durations before arriving at something that would satisfy both needs of your organization – teams’ need for predictability as well as the business’ need for flexibility.
Differences between Release backlog and sprint backlog are:
- The sprint backlog is part of the release backlog. So, these are two different views on the same product backlog (the release view looks at large slices of work; Sprint planning looks at smaller chunks).
- The sprint backlog is more detailed than the release backlog (it gets into implementation details), which makes it more suitable for executing – but also riskier because significant rework can occur if you realize, during execution, that some decisions taken in the prior sprint were wrong.
- You plan how much you can do within a sprint during Sprint Planning, while with Release planning there is only one option: define all items to be done until the next release/iteration starts.
- On principle, every item on the Sprint Backlog is estimated, even if the estimate is zero. This can be problematic because stakeholders may assume that they will not have to pay for items with zeros – however, this is not true!
- The end of a Sprint always ends in a review meeting (called Sprint Review) where you demonstrate what you have achieved during the sprint. At this point, everything set out in the Sprint Backlog should be ‘Done’ unless there are exceptional circumstances.
- You run Scrum meetings 3 times per day: Daily standup at 9 am, a 30-minute planning meeting at 2 pm, and an hour-long retrospective/review meeting at 3 pm.
- The most important artifact of Scrum is called Product Backlog Items (PBIs). These are individual features of the application that will be put into the application at some point in the future. We would not recommend writing actual code here as it can feel like a waste of time (remember – there is no such thing as a ‘throwaway’ line of code in Scrum, everything adds value to your software product).
The best way to explain this is through an example:
If you want to develop ‘a notification system that email and SMS the user when they receive a message, then this should be written down as one Product Backlog Item rather than three: – “a notification system” – “that email and SMS users when they receive a message” – “from admin/support staff”
- How to split up large stories: It is also worth considering that you may have more than one Product Backlog Item that is dependent on each other. These will be treated as sub-tasks of the overall block of work, for example: – “a notification system” -> “that email and SMS users when they receive a message” – “from admin/support staff”.
This is called splitting. We always recommend splitting out your high-level tasks into detailed tasks (which we call ‘user stories’) until it meets the following criteria: – It can be estimated by your team with reasonable accuracy (if not, then this is likely too big) – You understand the purpose of the task.