Two Important Scrum Artifacts

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 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

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.

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

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.

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.

Requirements: Exactly What Does the Customer Need?

One of the most important aspects of designing a system is requirements gathering. A company can have the most seasoned user experience professionals, top-notch developers and exceptional testers that catch every defect. But, will the customer be happy with a beautifully built, flawless product that isn't what was needed? Probably not!

For over 8 years I've worked as a business systems analyst; typically hired as a consultant after a project has failed. And, in most cases, the projects that failed did so because incorrect assumptions were made. And, requirements were then written from a mixture of inaccurate assumptions and customer statements.

The only way to accurately identify customer requirements is to ask questions. Ask questions and let the customer state his/her vision for the implementation. Be sure to ask about business problems and needs that may have initiated the need for the project. And, trace the applicable requirements from the stated problems/needs to make sure the project addresses these areas.

In short, to accurately design a business solution from requirements; the analyst must take on the role of a detective. He or she must search for unknowns; and, turn mysteries into concrete statements for feedback. At times the analyst will have to draw conclusions from provided information; and, clearly state those conclusions for feedback. Thorough investigative work is what it takes to accurately define a business solution.  But it also takes an understanding of the technology associated with the project.

It's also good practice to gain an understanding of any initial groundwork already laid for the project. For example, ask for a copy of the Statement of Work (SOW). Also, ask for existing system documents, system diagrams, and access to the current system, if applicable. And, in some cases, personal time may need to be used to read through the materials--if the deadlines are tight. But, it is worth it to put forth the effort to gain this insight prior to meeting with the customer. This allows requirements gathering sessions to be used to gather requirements.

Below is a list of tips you may find useful while meeting with customers to understand system requirements:

1. Ask for existing system or project documentation.

2. Be willing to use your personal time to learn concepts if deadlines are tight.

3. When meeting with the customer ask questions. And, make sure the stated business problems/needs are addressed.

4. Enter all requirements into a requirements management system.

5. Perform a gap analysis.

6. Write questions that will help close the identified gaps. Then be sure to obtain complete answers to those questions.

7. Update the requirements as you receive answers to your questions.

8. Generate a trace matrix or report for customer review.