Annotated Bibliography & Problem Statement

Agile_by_Design_An_Implementation_Guide_to_Analyti..._----_Chapter_13_The_Analytic_Sprint_Planning_and_Execution.pdf

Home >Business & Finance homework help >Operations Management homework help >Annotated Bibliography & Problem Statement

Chapter 13 The Analytic Sprint: Planning and Execution In our previous chapters, we've covered processes and activities within the Scrum framework. In this chapter, our analytic team gets rolling on its project with sprint planning activities. Team members timebox their sprint planning session at two hours and use the time to review roles and responsibilities, define a sprint goal, and select backlog items that they believe they can complete during the sprint, based on their velocity. The team incorporates a definition of done into the task estimation to ensure high-quality, customer-ready deliverables (see Figure 13.1).

Figure 13.1 The Product Backlog Evolves over Time

Committing the Team In Chapter 8 on analytic Scrum roles and responsibilities, we discussed three roles: the product owner, ScrumMaster, and development team, which can comprise any roles necessary to complete the work. In addition, you may identify a few extra roles that are important, whether related to organizational requirements or specific project needs. There's no one “right” team structure: As long as you have access to all of the knowledge that's required to get the work done, you can organize in whatever way makes sense.

Alt-Simmons, Rachel. Agile by Design : An Implementation Guide to Analytic Lifecycle Management, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=4041094. Created from harrisburg-ebooks on 2020-11-16 07:32:31.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Rebecca and Isabel review all of their planning documents. “We've got Sherry as our sponsor and Jason as our day-to-day product owner. Sherry's there to assist with any data preparation work and Sally as our dedicated IT liaison. Jeremy and Natasha will be doing the modeling work. I'll be the team's ScrumMaster, and I'd like to bring in Emily, one of our business analysts, to help the modelers with the documentation. That should do it for our full-time team. On an as-needed basis, we'll bring in the data SMEs. Since we're starting with the customer data, Jason will be working with us full-time for the next two sprints.”

Ideally, the core team is dedicated full-time to the project. With roles such as our data SME, whose expertise is only required for a specific component of the project, they don't have to be with the team for the duration. However, during the time that they're needed, they should be fully allocated and available.

The Players Table 13.1 is an overview of our team members, their roles, and a description of their responsibilities. Note that this is just a list of team members and is not reflective of all the stakeholders in the project. While Isabel leads the analytic team, she won't play an active role in the execution of the work.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Table 13.1 The Players

Person Role Description Jim Allen, AVP of Customer Service

Product Owner

Jim will provide the day-to-day guidance on the direction of the project, including the prioritization of the team's product backlog.

Rebecca Gonzales, Project Lead, Analytics

ScrumMaster Rebecca's role is the ScrumMaster. She'll ensure that the team has everything they need to be successful.

Natasha Stoykova, Lead Data Scientist, Analytics

Development Team Member

Natasha is the most experienced analyst on the team and provides analytic coaching to other team members.

Jeremy Liu, Jr. Data Scientist, Analytics

Development Team Member

Jeremy will work closely with Natasha to complete the analytic work.

Sarah Martin, ETL Specialist, Analytics

Development Team Member

While Sarah's specialty is ETL and data integration, she has profiling and basic statistical skills.

Sally Martinez, IT Operations

Development Team Member

Sally is primarily the IT liaison, but also supports the data environment and can help with data extraction and profiling tasks.

Emily O'Brien, Business Analyst, Analytics

Business Analyst

Emily assists the team in completing the definition of done, by helping to capture the knowledge gained during the analysis and formulating the reports and visualization needed in the sprint review.

Jason Chu, Director of Customer Service

Data Subject Matter Expert, Customer Data

Since the focus of this sprint is on customer data, Jason will assist the team in selecting the right data elements and interpreting their business context.

A key tenet of Scrum is that the Scrum team is self-organizing. This means that the team determines who the work will be assigned to within the team and how it will be completed. As outputs of the sprint planning process, the Scrum team knows what the sprint goal is and what backlog items will be delivered during sprint execution. Also within sprint planning, the team creates a plan for completing product backlog items assigned to the sprint. This effort does not involve creating a detailed project plan or Gantt chart for the sprint. Scrum is designed to let teams learn by doing, and this learning process is disruptive to detailed planning. That said, a

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

level of up-front planning is helpful in identifying task-level dependencies, but should be limited to the knowledge the team has at hand. Teams that apply task planning continuously during the sprint will assist them in adapting to change.

Sprint Planning

Rebecca assembles the team for its first two-hour sprint planning meeting. Isabel and Sherry are conspicuously absent.

“Hey, where's Isabel?” asks Jim. “I thought she would be here?”

“Isabel participates in the prioritization and upfront planning that we do prior to project execution, but once a project gets rolling, the team takes over,” says Rebecca. “Since this is the first planning meeting we're having as a team, let's go over some of the ground rules and expectations. In our meeting last week, we groomed our product backlog and identified our first area of focus—the customer data in our CDW. Our first step is to define the sprint goal.”

“Remind me again,” says Jim, “what's a sprint goal?”

“The sprint goal gives our Scrum team a target for our first sprint. As the product owner, you get to define that goal, keeping in mind the work that's on the backlog and our capacity —or velocity, the amount of work the team believes they can complete in a sprint—to complete the work within our one-week sprint time frame.”

Velocity Teams measure the amount of work completed in a sprint by calculating their velocity. Velocity is calculated by adding up the size of the product backlog items completed at the sprint's finish. Partially completed product backlog items do not count in a team's velocity metric. Velocity measures the team's output, not the value of the output.

A team's velocity plays a critical role in Scrum planning processes. At the release-level, the team adds up the total story points within a release and then divides that by the team's average velocity to come up with the number of sprints within the release. Velocity is also used as an input for evaluating and improving the team's processes. By reviewing velocity over time, the team can analyze the impact of process changes on its ability to deliver customer value.

If your team is brand new or the type of project you're delivering is new, you won't have any historical velocity metrics to use during the planning process. In that case, the team needs to forecast velocity. One method would be to have the team plan out a sprint and estimate the number of product backlog items that the team believes could be completed during the sprint. For the release plan, that estimated velocity could be used in place of average velocity. Once a sprint has been completed and the team has an actual velocity measure, the team can re-

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

estimate the release plan.

“Since this is a new project, we took a stab at calculating velocity for our first sprint,” Rebecca tells the team. “We have five development team members. Our sprint one work will be heavily weighted toward data extraction and profiling, but the entire team has the skillset to participate in those activities. On a typical project, we use a 32-hour workweek. This helps us account for any administrative time and other meetings that take place throughout the week. If we multiply 5 development team members by 32 hours per week, we have 160 person-hours per sprint. Working from our product backlog and aligning to the sprint goal, we'll tackle that amount of work in our sprint.

“What we might find down the road,” she continues, “is that we have more capacity, or we have opportunities to improve our estimation. All those things will go into future sprint planning sessions. But this gives us a good starting point.”

Task Definition The team decides what tasks need to be accomplished to complete a product backlog item. While managers and product owners may provide input into task-level work (by defining the scope of the feature and the acceptance criteria), they must trust and empower the team to define and organize the completion of that work.

The nature of the business requirements may also influence how the work is completed. For example, if the team needs to deliver customer-ready work in a production environment, there may be more work effort involved for customer-readiness. If specific technical decisions are made that have business and/or financial consequences, they need to be taken into account in a way that makes sense for the business. These types of requirements would be included in the team's definition of done.

Teams should decompose stories into tasks that can be completed in a few hours. The definition of tasks at a granular level helps enforce discipline to develop and deliver small increments of functionality.

Rebecca hands out the current product backlog that the team worked on in its initial grooming session, shown in Table 13.2.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

“Perfect,” says Jim. “I want the first sprint goal to be this: Identify available customer attributes that could influence retention.”

“That's a great start,” says Rebecca, “but the team needs to ensure that they can complete all of these tasks within the sprint. Team, what do you think?”

“I think it's reasonable,” Natasha looks over the task list. “We went over this while we were grooming. This totals up to 107 ideal hours. We believe our velocity is 160 hours. I think this is a good starting point since this is our first sprint. If we find that we have excess capacity, we can take on additional work, but we absolutely don't want to take on more work than we know we can finish.”

Table 13.2 Analytic Sprint Tasks

Hypothesis Data Source Data Tables

Data Stories

Tasks

Customer attributes influence retention

CDW External customer demographic

Table 1 Table 2 Table 3 Table 4

How old are customers? Where do they live? What is their income?

Extract customer data from CDW (5 hours) Create master customer file (16 hours) Extract and merge external data with customer data (20 hours) Land data in analytic sandbox (2 hours) Profile and assess data (24 hours) Perform cluster analysis (8 hours) Complete data assessment report (8 hours) Document data sources (24 hours)

The team agrees on the sprint goal and begins to decompose some of the tasks in the backlog. As a general rule, tasks longer than eight ideal hours in duration (the amount of time a task would take without interruptions) should be broken down into more discrete tasks. For example, the task labeled “create master customer file” might be broken down into tasks like:

Take customer attribute table and append to customer table.

Aggregate data by household.

Append additional customer tables.

Cohn (2004) recommends the following guidelines for task decomposition:

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

If one task of a story is difficult to estimate, separate the task from the rest of the story.

If tasks can be easily completed by separate developers, then split those tasks.

If there is benefit in knowing that part of a story is complete, then break that part out as a separate task.

The Team's Definition of Done The purpose behind creating the definition of done (DOD) is to ensure that the team delivered completed work to its customers. All too often, teams take shortcuts to get the work out the door: A solid DOD helps the team deliver high-quality results to stakeholders and minimizes technical debt. DOD tasks are included as part of the team's estimates. Following are examples of tasks for the team to consider—some of these may be encompassed in the definition of done and would be incorporated in every data story or hypothesis the team is working on. Keep in mind that you don't have to go overboard on this—your team should create a DOD list that makes sense for the organization and adds value to your stakeholders (including your team!).

Story elements: Tasks for any additional whiteboarding or discussion needed around hypothesis or data story clarification.

Code checks: Create a task for validating model dataset ETL or other code.

Nonfunctional requirements: Tasks to account for any security, performance, usability, testability, maintainability, extensibility, scalability, and regulatory needs; these tasks become more important as the predictive models move out of development and into operational deployment.

Peer review: Peer review of analytic methodology, assumptions, results, coding, ETL, and so on.

Code refactoring: Tasks for restructuring of model development code in an efficient manner; again, a task like this may be more critical to production deployment of a model. For example, an ETL developer may refactor an analyst's data preparation or integration code to conform to production standards.

Exploratory testing: Ad hoc testing to ensure nonfunctional requirements specifications have been met.

Data defects verification and fix: Allocating the appropriate time for validation and verification of analysis or results prior to sharing it with stakeholders.

Documentation: Tasks for updating any data dictionary or knowledge repository with the appropriate documentation (data profiling results, data sources and definitions, statistical analyses, etc.).

End-user documentation: Tasks for creating any materials (reports or visualizations) used to communicate findings to stakeholders.

Your DOD may be project specific, team specific, or a combination of both. For any strategic Alt-Simmons, Rachel. Agile by Design : An Implementation Guide to Analytic Lifecycle Management, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=4041094. Created from harrisburg-ebooks on 2020-11-16 07:32:31.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

project, Isabel's team uses a DOD that starts with specific team requirements and layers in any additional requirements required by either IT or the business stakeholders. For example, if the team is working on a project that uses confidential data, the team adds in criteria to align organizational data security standards.

Organizing Work Most simply, the team may select the highest- priority items to work on as defined during the sprint planning session. This ensures that items not completed by the end of the sprint are of lower priority. However, this approach may not be realistic due to technical dependencies or skill capacity, which may force the team to complete work in a different order. This is an important consideration for the team members as they plan their work. In our project, there is some sequence to the work, meaning that there is task dependency. For example, you might not be able to start profiling until the data have landed in the sandbox. However, you might be able to start profiling individual data sets before the aggregation work is complete.

Once a backlog item has been selected, the team determines how to perform the task-level work. It's important for the team to get away from the waterfall mindset: Work can be ordered in any way that is effective for the team. The team also needs to get away from thinking about role-based work. Agile teams often share responsibilities or take on different roles during development. This minimizes idle time and reduces the number of handoffs throughout the development process. In this sprint, all of our team members have basic data profiling and analysis skills, so that work could be shared.

Once the tasks have been identified, team members will typically volunteer to perform a task. The team member responsible for the task records his or her name next to the task (perhaps on a whiteboard or within an agile software management tool). Even if using pair-programming during development, one person should accept responsibility for task completion. But it's important to keep in mind that the team is in this together: The group shares responsibility for ensuring that everything is completed.

Sprint Zero Although it might sound counterintuitive since there's no customer value in it, the team may initiate a sprint zero before beginning to work on development tasks. Within sprint zero, team members focus on getting things ready for the development process so they can hit the ground running in their first sprint. This could include developing the release plan and backlog, infrastructure set-up, and architectural design considerations, and establishing team practices and standards. Many Scrum practitioners advocate against a sprint zero, but it may be appropriate for the team if some of the following conditions are in place:

New Teams The team may need some time to organize and discuss how it will work together. For new analytic projects, engaging IT and the business and developing those relationships will take some time.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

New Infrastructure, Tools, or Methods If the team doesn't have any experience with a certain programming language, software application, hardware configuration, database environment, and so on, you can use this time for training or level setting.

Geographic Distribution or Cross-Team Work Efforts Use this opportunity to ensure that the team's communication/collaboration tools are working well and that the environment works from different geographic locations.

Sprint zero is not required, but may be useful for teams that are just getting started. As with any sprint, the team should define a sprint goal to work toward. A successful sprint zero enables the team to begin development quickly in sprint one. Keep your sprint zero timeboxed so you don't end up in an infinite no-customer-value analysis phase.

Often, in a new analytic project, the team may be testing a new technology or capability. If there is a dependency in your project on one of these capabilities, make sure you have the tools in place to begin the work in your sprint. It's absolutely appropriate to layer in technology capabilities over time, but you want the minimum infrastructure in place day one to get started. If your team needs training on some new capability within the duration of your project, carve out the time in a knowledge-gathering spike.

Sally reviews the product backlog. “The big data infrastructure we're putting up in Hadoop won't be ready for a couple of weeks. We'll need to defer any data stories related to web data until that's in place. I'll continue to work with that team so we're kept in the loop.”

Sprint Execution

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Once the foundation has been laid, the team begins its work. The data begin to roll into the analytic sandbox, and the team members begin their profiling work. At the team's daily standup on day three of the sprint, it's Natasha's turn to speak.

“Since yesterday, I've been working on profiling our customer data sources. I'm going to continue the profiling work today, but we've got some issues with the data that need to be addressed before we can move forward.”

“Can you give me a quick overview?” says Rebecca.

Natasha continues, “As we were preparing the data, we discovered that many of the data fields were never entered with the understanding that it would be used for analysis. For example:

“Many fields are not required, meaning that they could be left blank, allowing for a large amount of missing values.

“Most categorical fields do not have well-defined levels. This means that at one point in time, a categorical level could be assigned a value and then a few years later, another categorical level meaning essentially the same thing could be assigned a different value. This results in a larger number of values for that category.

“There are inaccurate date values associated with birthdates and other customer expiration dates.

“Jason and I have been working through why some of this is happening and Emily is documenting it, but this is a discussion point for the broader team. We've got some ideas on how to work around this. I recommend that we continue work on the assessment during this sprint and then use our sprint review time on Friday to discuss with our customers.”

“Is there anything else I can do to help you?” asks Rebecca.

“I think we're okay for now. We'll give you another update tomorrow morning.”

This is a good example of why a one-week sprint works well for this analytic team. The sprint review checkpoint provides frequent enough checkpoints with the business stakeholders so that critical issues like these can be addressed. If the analytic team moves forward with its own solution without consulting the customers, then the team runs the risk of producing results that the business may not trust. This also illustrates the importance of having a dedicated product owner and data SME on the team. While these problems in our team's project are not insurmountable, it requires a conversation between the team and the stakeholders.

Summary The analytic Scrum team begins its first sprint in a sprint planning session. Once the sprint goal is defined, the team selects the appropriate amount of work that the team members reasonably believe that they can complete during the sprint. As the team initiates the project, a “sprint

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

zero” may be helpful for preparing the environment and infrastructure. Defining tasks in accordance with the team's definition of done is critical for a successful sprint. The team self- organizes: Once tasks are defined, the team determines who will perform the work and how it will be completed. The team leverages technical development practices in performing the work through its definition of done.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed