Sprints only go as well as the shape of the product backlog. Having a good product backlog is key to being able to deliver software in a Scrum fashion. There are very few required elements to generate an adequate backlog for beginning Scrum. These elements are:
- Forced ranking
- User Story
- Acceptance Criteria
- Size
The first steps are to get customer facing features ranked by their expected ROI and risk. If the backlog is a list of requirements, functional, and task-based, Scrum will be of little use. If the customer or Product Manager understands how to write effective user stories, then Scrum can proceed.
The next step is for the development team can estimate the size of the features, related to each other in order of magnitude. I personally like using Planning Poker for determining size. If this step is skipped, determining velocity and predicting dates is impossible. Once again, the value in Scrum is lost.
The discussions when sizing the backlog will likely lead to re-ranking the features. There will be a clearer understanding of the technical feasibility, complexity, value and risk. The backlog should now be in good enough shape to start sprinting. At planning, the product owner should enumerate the acceptance criteria for a story, before the tasks are planned. This criteria relates what the behaviors of the feature would be if it is in production.
Having a backlog with these elements allow a development team to sprint effectively. Not having these elements puts Scrum in jeopardy. If you’re in a team that is sprinting and find these elements are missing, this could be a good topic to determine if your team is actually using the Scrum process.