Scrum is the most popular Agile Framework. Almost every software development team in the world is using some aspects of Scrum framework in some shape or form. However most Scrum implementations that I have seen are missing some crucial parts of the recipe preventing them from achieving the exceptional results promised by Scrum. PRODUCT BACKLOG Product backlog is an ordered list of various work item that needs to be done. These work items are called Product Backlog Items (PBI). Items at the top of the backlog have higher priorities and items at the bottom of the backlog have lower priority. No 2 items have the same priority. Every item has more priority than the item below it and less priority than the item above it. The product backlog is not a queue and can be constantly reprioritised and changed by the product owner. Items at the top of the backlog are more refined and are more ready for the team to start working on and items lower in the backlog are larger and more abstract. PBIs can be various things including but not limited to requirements (user stories), bugs, Spikes and research tasks, tech debt, etc. SPRINT BACKLOG The sprint backlog is the plan that the team comes up with for the sprint. The sprint backlog is owned by the developers. The order of items in the sprint backlog is decided by the dev team not the product owner (unlike the product backlog). The product owner cannot make any changes to the sprint backlog. If the product owner needs to absolutely make changes to the sprint backlog in certain circumstances, they will void the commitment/forecast of the team to deliver what they said they will in the sprint. BACKLOG REFINEMENT Backlog refinement (A.k.A. Backlog Grooming) is the process of refining and preparing the PBIs for the upcoming sprints. Typically there is a backlog refinement meeting to talk about and estimate the PBIs prior to the sprint planning. The better we prepare and refine the PBIs before the planning meeting the shorter and easier the planning meeting becomes. SPRINT Sprint is a short timebox where the team refines, builds, and tests PBIs. At the end of the sprint a potentially shippable product implement must be produced. Typically sprints are 2 weeks but it can be really any length, I have seen 4 week sprints, 3 week sprints, 2 week sprints, 1 week sprints and even 2.5 day sprints. It is a decision that needs to be made according to the context. Not that once we set the sprint length we don’t want to change it and we want to keep the cadence. Every sprint the team iterates and goes through the same process again, incrementally delivering potentially shippable product increments.