As I mentioned in my previous blog post “The Agile Team and What is a Backlog?,” the sprint backlog is a major components in the agile development methodology. The sprint backlog is the list of the tasks needed to meet the requirement in the product backlog and an estimated completion date for each task. As mentioned by Pikkarainen et. al (2008), a sprint backlog is a necessary tool “for the requirements and task definition (p. 315)” and when planning the sprint, it is important that the tasks are prioritized based on what the product owner wants (p. 317). Once the tasks are listed in order of importance, the team must estimate and vote how much time should be invested in each task. Planning poker is a technique used in software development to aid in estimating.
For people who are new to agile, like my team, for example, estimating can be quite challenging. New teams tend to be overcautious because of unfamiliarity with the process, which then leads them to overestimate. When my team met with our clients, Bruce Keeler and Gina Ciardella, both SJSU College of Science advisors, we were asked for an estimate for our upcoming deliverables. The main task needed for our current sprint is to provide a new layout for the College of Science Advising Center website. Since we are all new to this sort of project, we informed our client that it will be ready in two weeks. Although we all know that we can finish the said task for a couple days, we overestimated “just to be safe.” Playing planning poker helps eliminate this kind of common mistakes in the estimation. The team votes for a time and also explains why they vote for that specific time frame. Hence, they will hear everyone’s insight and can better come up with a close estimate in the following rounds.
The meaning of “done” in Agile is defined and agreed upon by the team and depends on what tasks are voted on the sprint. Usually, a sprint is considered done when the features listed in the user stories are developed and tested. Some groups may consider a sprint done if the functionality of the highest importance is completed. Just like how a product backlog changes over time, the definition of done also changes throughout the sprint. According to Begier (2010), the product owner’s analysis of the deliverables on each sprint allows to specify improvement (p. 390). The team will need to adjust to any modifications made by the product owner. A project is considered entirely done if and only if the product owner accepts the final demonstration and stops making revisions to the latest product backlog.
Begier, B. (2010). Users’ involvement may help respect social and ethical values and improve software quality. Information Systems Frontiers, 12(4), 389-97.