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: Understanding the Customer's Vision

Establishing the Vision

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. You can manage this information by creating a list of business problems and/or needs. Ultimately, all requirements and problems/needs should be managed using a requirements management system such as RequisitePro.

 

Problem/Needs List

1.1 NEED:  Need a dashboard that reflects current sales by region

 

1.2 PROBLEM: Currently, end users are not able to associate a customer order with a region (data can only be associated with a city and state). Should we have the system assign the region based on the city/state? How can we fix this problem?
1.3 NEED:  Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 PROBLEM: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?

 

Notice, with each problem the customer realizes that it’s a problem; but the need that will be used to fix the problem has not been identified. Ultimately, all problems should be translatable to a definite need that everyone agrees on. Following is the updated Problems/Needs list with the problems translated to a need. (Note that with requirements it is good to keep all of the information in place and add notes as changes are made. Then as questions arise as to where the requirement came from, you have the historical data to refer to.)

Problem/Needs List UPDATED

1.1 NEED:  Need a dashboard that reflects current sales by region
1.2 NEED:  Add region data added to the database.  Need to get the CD from the Post Office that includes city, states and zip codes. Verify that the region data is also included. If not our DBAs will need to add the region data.  (Description for the need is: This need resolves 1.2 Problem:  Currently, end users are not able to associate a customer order with a region (data can only be associated with a city and state). Should we have the system assign the region based on the city/state? How can we fix this problem?)
1.3 NEED:   Need to be able to generate reports for segment marketing. We need to implement a business intelligence solution.
1.4 NEED:   Need a Customer Support Role. This role should be the only role with the right to add a customer order. No other roles should be granted this right. .  (Description for the need is: This need resolves 1.4 Problem: All employees can add order records, when only Customer Support should be able to add order records. What’s the best way to address this problem?)

 

Once the problems/needs list has been completed you will need to ask about the Features the system is to support. Features are the highest level of requirements.  The features will ultimately be used to organize the use cases.

Following is a list of features to provide an example of what a feature might look like:

 

Produce Features

 

1.     Manage Customer Records

2.     Interface with the XYZ Accounting System

3.     Generate Business Intelligence Reports

4.     Manage Sales Records

5.     Manage Employee Records

6.     Manage Customer Orders

 

Both the Problems/Needs list and the Product Features are added to the Vision document, which includes other information such as information about the stakeholders (individuals who are directly impacted by the success or failure of the projects). The Analyst should ask stakeholders whether or not they have any type of success criteria. A success criterion is a requirement that the system or project must meet for the project to be viewed as a success. For example, a success criterion may be that the system must be in place by a specific date. If this is the case adding a priority to your features, use cases and functional requirements become critical. When you have short timelines, you will need to work with the stakeholders to prioritize the requirements. Requirements marked with a “High” priority are implemented first. Then the “Medium” priority requirements are implemented once all “High” requirements have been successfully implemented. Lastly, your “Low” priority requirements are implemented once the Medium priority requirements have been implemented.  The following table shows an example of the High, Medium and Low priorities mapped to features, use cases and functional requirements.

 

 

Features	Feature Ranking = High	Feature Ranking = Medium	Feature Ranking = Low
Use Cases	All Use Cases = High priority	Approximately %50 of use cases = High priority – ONLY IMPLEMENT THE USE CASES MARKED AS HIGH.	Less than %50 of use Cases = High priority– ONLY IMPLEMENT THE USE CASES MARKED AS HIGH
Functional Requirements	All functional requirements = High priority	Approximately %50 of functional requirements = High priority– ONLY IMPLEMENT THE FUNCTIONAL REQUIREMENTS MARKED AS HIGH	Less than %50  of functional requirements = High priority– ONLY IMPLEMENT THE FUNCTIONAL REQUIREMENTS MARKED AS HIGH

 

 

In addition to adding information about the stakeholders, information about the end users of the system is also included in the Vision document. Other information included in the Vision document includes the technical documentation and end-user training requirements as well as a high-level list of other requirements such a performance. Once the features have been identified, the use cases are defined and added to the use case specification.  Then the functional requirements are defined and added to the software requirements specification.

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.

Summary
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 between the current system, the business problems/needs and the use cases and functional requirements. If a business need has not been translated into an actionable requirements be sure to translate it to either a use case or functional requirements—based on the need and how it is to be implemented.

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 customers to review.