Scrum is a framework that compresses Software Development Life Cycle (SDLC) activities in to shortened projects called Sprints. With Scrum a Sprint typically lasts 30-days or less. This article looks at two important artifacts used by the Scrum team during a Sprint: The Product Backlog and the Sprint Backlog.
The Analyst works with the Product Owner and/or other stakeholders to understand key requirements for the business application including whether the software product is to integrate with other products. And, if integration is necessary what are the names and brief overviews of the applicable product(s). Also, as part of the Vision the Product Owner discusses who the users are, the business needs and the problems the completed solution is to address. One of the key artifacts developed from these requirements gathering sessions is the Product Backlog. The Product Backlog includes a list of the features, justification for each feature, dependencies, value rating, the risk associated with implementing the requirement and the priority. The risk is typically associated with the complexity of the requirement to be implemented. For example, developing an interface between two different systems is riskier than building a component used to generate reports. The priority will be used to decide what requirements are implemented for each Sprint. This means, typically High requirements are implemented before Medium requirements. And, Medium requirements are implemented before Low requirements.
The above picture is a sample initial draft of a Product Backlog for an imaginary Help Desk Management System project. The Development Team is expected to rebuild an existing Help Desk System because the technology is outdated and the system lacks many features that would help the Help Desk team provide improved support.
Once the initial Features are defined the Business Analyst or Systems Analyst meets with the Product Owner and other assigned stakeholders to gather more detailed requirements. The Analyst is asked to document user stories and notes for the first 5 user stories, which the Product Owner hopes can be completed during the first Sprint. During the Sprint Planning Meeting the Product Owner plans to circulate the Product Backlog and ask everyone to focus on user stories US1.1 – US1.5.
The Product Owner wants to make sure discussions remain within scope for the project. And, the Product Owner wants to make sure the team has a firm starting point so the meeting is structured and everyone is on the same page regarding the direction of the Help Desk System for the first Sprint.
Lastly, to me this group has a challenge. This is this group’s first Scrum meeting. Since this project does not have past information to lean on, the Product Owner has asked each team member to discuss issues, concerns, lessons learned, etc. from past projects. This provides additional insight the Scrum Team can use to guarantee the success of the Help Desk Management System Project.
Over the course of the Sprint Planning Meeting the Development Team (including the Web Developers, Systems Administrator, Database Administrator, Testers, Deployment Manager, Technical Trainer and Technical Writers (or any variation of these roles depending on the organization and project type (i.e., commercial or government))) provide input, as applicable. The objective is to come up with an artifact that catalogs all of the work that must be completed to fully implement the requested scope of user stories. The person in the meeting taking minutes will create a list of all the tasks and the name/title of each person stating the task(s) he/she must perform to help complete the work. This is the Initial Task List discussed in my previous article titled Agile User Stories & Test Cases.
Once every task is accounted for, the team has the information needed to create a draft of the Sprint Backlog. The Sprint Backlog details the work to be completed over the course of the Sprint. Days are associated with each task to track where the team members should be on any given day of the project. The Scrum team now knows the scope of work (what user stories are to be implemented) and all of the tasks needed to turn the requirements into an operational product that can be deployed and used. To solidify its deliverable the Scrum Team defines the Sprint Goal. This is the overall objective that will be met by completing the identified scope of work. In this example, the team is expected to deliver a product that allows the “Help Desk Analysts to Add, View & Update Support Tickets”. After evaluating all tasks necessary to complete the requested scope of work, the team commits to completing user stories US1.1 to US1.5 for the first Sprint. But, keep in mind (with Scrum) the Development Team could have asked to have one or more user stories removed from the first Sprint.Ultimately, it's up to the Development Team to convey how much can realistically be accomplished during a Sprint.
Scrum provides a framework that makes it easier for project teams to complete SDLC activities to yield a specific scope of functionality. The Scrum approach is much different from the detailed Rational Unified Process, which leaned more heavily on detailed specifications that took several months to implement. However, it should be noted that some argue that Scrum was not designed for more detailed, complex projects. And, in actuality it may not have all of the artifacts needed to support a complex project that includes interface engines and servers to share messages and data across a widespread region. But, many organizations implementing less complicated business applications stand behind the Scrum approach.
The Product Backlog
With Scrum, one of the most important meetings is the Sprint Planning Meeting. Prior to this meeting the Product Owner works with the Business Analyst or Systems Analyst to define the features and dependencies associated with the business application to be developed or updated.
The Analyst works with the Product Owner and/or other stakeholders to understand key requirements for the business application including whether the software product is to integrate with other products. And, if integration is necessary what are the names and brief overviews of the applicable product(s). Also, as part of the Vision the Product Owner discusses who the users are, the business needs and the problems the completed solution is to address. One of the key artifacts developed from these requirements gathering sessions is the Product Backlog. The Product Backlog includes a list of the features, justification for each feature, dependencies, value rating, the risk associated with implementing the requirement and the priority. The risk is typically associated with the complexity of the requirement to be implemented. For example, developing an interface between two different systems is riskier than building a component used to generate reports. The priority will be used to decide what requirements are implemented for each Sprint. This means, typically High requirements are implemented before Medium requirements. And, Medium requirements are implemented before Low requirements.
 |
| Draft of the Product Backlog Artifact |
The above picture is a sample initial draft of a Product Backlog for an imaginary Help Desk Management System project. The Development Team is expected to rebuild an existing Help Desk System because the technology is outdated and the system lacks many features that would help the Help Desk team provide improved support.
The Sprint Planning Meeting
The Product Owner wants to make sure discussions remain within scope for the project. And, the Product Owner wants to make sure the team has a firm starting point so the meeting is structured and everyone is on the same page regarding the direction of the Help Desk System for the first Sprint.
Lastly, to me this group has a challenge. This is this group’s first Scrum meeting. Since this project does not have past information to lean on, the Product Owner has asked each team member to discuss issues, concerns, lessons learned, etc. from past projects. This provides additional insight the Scrum Team can use to guarantee the success of the Help Desk Management System Project.
 |
| Product Backlog |
Creating the Sprint Backlog
With the Product Backlog available for review along with the user story index cards, the team is ready for a productive Sprint Planning Meeting. During the Sprint Planning Meeting each member of the Development Team brings expertise to define all tasks that must be completed to make the Sprint a success. Everyone will review all of the work that must be completed to implement the five user stories before agreeing to the work.
Over the course of the Sprint Planning Meeting the Development Team (including the Web Developers, Systems Administrator, Database Administrator, Testers, Deployment Manager, Technical Trainer and Technical Writers (or any variation of these roles depending on the organization and project type (i.e., commercial or government))) provide input, as applicable. The objective is to come up with an artifact that catalogs all of the work that must be completed to fully implement the requested scope of user stories. The person in the meeting taking minutes will create a list of all the tasks and the name/title of each person stating the task(s) he/she must perform to help complete the work. This is the Initial Task List discussed in my previous article titled Agile User Stories & Test Cases.
 |
| Sprint Backlog |
Conclusion
Scrum provides a framework that makes it easier for project teams to complete SDLC activities to yield a specific scope of functionality. The Scrum approach is much different from the detailed Rational Unified Process, which leaned more heavily on detailed specifications that took several months to implement. However, it should be noted that some argue that Scrum was not designed for more detailed, complex projects. And, in actuality it may not have all of the artifacts needed to support a complex project that includes interface engines and servers to share messages and data across a widespread region. But, many organizations implementing less complicated business applications stand behind the Scrum approach.
