Software development doesn't always go as planned. According to a study published in the Portland Business Journal, between 65 and 80% of all IT projects fail to meet their objectives while also running “significantly late” and costing more resources than the developer had initially planned. Statistics such as this reveal the problematic nature of traditional methods of software development. But developers and organizations that embrace scrum will often avoid these headaches, delivering higher quality software in less time.
What is Scrum?
Scrum is a framework of Agile that's used to manage product development. It emphasizes the use of incremental sessions, known as “sprints” where the development team works together to achieve a single common goal. According to Scrum.org, scrum is a “...management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically. “
If you're interesting in using scrum in your organization, however, you'll need to familiarize yourself with the framework's artifacts. There are typically five artifacts used in scrum (exact number may vary), each of which has its own respective purpose.
The first scrum artifact that we're going to discuss is the product backlog. Consisting of an ordered list of requirements to achieve the scrum team's end goal, it's a vital component in the scrum framework for managing product development. Common items used in the product backlog may include product features, security fixes, patches and updates and system requirements.
Items are typically added to a product backlog as a story. Think of it like this: product backlogs are lists of what will be delivered, ordered in the manner that they should be delivered. Everyone can see these items, although only the product owner or someone with consent from the owner can change them.
Some people assume that product backlogs are nothing more than user stories. As explained by Scrum Primer, however, this isn't the case. “Contrary to popular misunderstanding, the Product Backlog does not contain user stories; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful.”
Another scrum artifact is the sprint backlog, which is essentially a list of work that the team is planning to tackle during the next sprint session. Scrum teams create this list based on items included in the product backlog, prioritizing the items at the top of the list first until they've covered enough work to meet the demands of sprint.
The scrum team must balance a fine line between productivity while maintaining realistic expectations when creating a sprint backlog. If they attempt to cover too many items from the product backlog during the sprint backlog, it could overburden the team to the point where they are unable to fulfill them.
The product development team has full control over the sprint backlog. They create the sprint backlog, and only they can add new work to it. Depending on the team's preference, a task board may be used in conjunction with a sprint backlog to analyze and modify the state of various tasks scheduled in the sprint, such as “to do,” “finished,” or “still in progress.”
The product increment, also known simply as an increment, is the sum total of all backlog items completed during a sprint, as well as all backlog items completed during previous sprints. When the team completes a sprint, a new increment is created for the working product – keyword being “working.” This means the product must be in working, functional condition, even if it's not released to the public.
The scrum team must decide among themselves what is a product increment. Generally speaking, a product increment occurs when the product is in working order to the point where it can be used as intended, although not necessarily for launch or release.
Sprint Burndown Chart
The sprint burndown chart, not to be confused with an earned value management chart, is a publicly displayed visual representation of the team's unfinished work compared with how much time they have left in the respective sprint interval. Its primary purpose is to predict when the work and/or project will be completed, allowing for greater accuracy regarding launch dates. In addition, sprint burndown charts offer a source of reference for the development team and other individuals working on the project.
Sprint burndown charts typically display the following information:
The ideal trend line in which the team breaks down the efforts that remain constant by the end of the sprint.
The in-progress series, revealing how many hours are left for each of the tasks marked as “In Progress” in the sprint.
The to-do series, revealing how many hours are left for each of the tasks marked as “To Do” in the sprint.
Release Burndown Chart
The release burndown chart is the fifth and final scrum artifact. It offers a functional means for the development team to track their progress towards completing the product. Teams can use this chart to determine what work has been finished and what work still remains. The scrum team master is responsible for updating the release burndown chart at the end of each sprint session.
A typical release burndown chart features a horizontal axis on which the sprints are displayed, and a vertical axis on which the remaining amount of work for each sprint is displayed. You can see an example of a scrum release burndown chart by clicking here.
Thanks for reading and feel free to let us know your thoughts in the comments below regarding scrum .