Agile in Data Science: How can Scrum Work Effectively for Your Team? | by Rose Day | Towards Data Science

Let’s dive deeper into acceptance criteria, story points, and sprint reviews! Using Agile Scrum on a data science team is hard, but it doesn’t need to be impossible. The past year I have worked on a heavily research-focused data science team, using Scrum to define, prioritize, and plan work. On this team, we have a set of 3 product owners overseeing the three scrum teams. Our product owners are also part of the development team, splitting their work 75% product owner duties and 25% development duties. We have adapted software methodologies to work to our needs, and I want to discuss how you can do the same.
Scrum is an Agile framework used to address complex problems through effective team collaboration, and incremental builds every 2 to 3 weeks your products. For data science teams your products may be something like analytics development. In Scrum, you have a product backlog and a sprint backlog. The product backlog consists of all work that needs to be done on a specific product or team. A sprint is 2 to 3 weeks’ worth of work, and each sprint, you define a sprint backlog of work from the product backlog. This work is what will be done during that 2 to 3 weeks.
On a Scrum team, there is the product owner and development team. The product owner is the individual that creates the product backlog items, orders those items to achieve the goals of the team best, and ensures the development team understands the items in the backlog. The development team is the individual who will implement the work in the backlog.
These individuals will work on user stories during the sprint. A user story is a specific work item that the development team must work on throughout a sprint. Depending on how much work is required for a given user story, data scientists on the development team may have one or more user stories to work on each sprint. Defining user stories on a Scrum data science team is one area in which I have seen problems arise. This is due to the open-ended nature of research based tasks that could evolve over time. The main areas I have found useful to fill in for each user story include:
Title and Description — These two items define what the work needs to be done. They should include enough information for the data scientist to take the work item and begin implementing it.
Acceptance Criteria — These are the foundation of what is expected of the data scientist. The acceptance criteria define out what is to be complete by the end of the sprint.
Story Point Estimation and Iteration — Together, these two values explain how much levels of effort is needed to complete an item and in which sprint does the work fall under. Ideally, a user story should be one sprint worth of work or less. If the user story takes longer than one sprint, then it should be broken into more than one story.
After you have defined your story and assigned it to a sprint, you will see your completed story on your sprint board. This is where you can see all work being done that sprint and any related information your development team likes to add to their stories as they work on an item.
Acceptance criteria can be hard to define for data science teams, especially when working with open-ended problems or investigations. Working on a research team means some tasks can be more challenging to define. But these tasks are not impossible. Before bringing a story to a sprint, acceptance criteria need to be determined. The product owner and the data scientist working on the user story should have some understanding of what is the expected outcome of the work.
The way I have approached acceptance criteria is to define one or more items that are expected at the end of a sprint from this work. Ask yourself, what do I want to achieve in the next few weeks? What decision or outcome do I want to arrive at?
For example, say you are creating a user story to research a new machine learning technique and you need to decide if you should use it or not in your work. You can develop your initial user story to do this research and define acceptance criteria as the outcome of that decision. That outcome will help you determine if you create more stories to continue the work or stop based on what you found. Below, I have defined the acceptance criteria in three bullet points. I want the data scientist to understand the technique, to determine how it could be useful to our work, and determine if we continue research to develop an MVP notebook. At the end of the sprint, the data scientist should be able to tell me if we continue with the work or not, and why.
Acceptance criteria can include an action plan for the next steps, a paper or presentation of the outcome, or a decision (go or no-go to continue work).
1. Define the expected outcome of the work. What is it that you want to know or have done by the end of your 2 to 3 week sprint? Are you looking to have a go/no-go decision made by the end of the sprint, an action plan for the next steps, or another output like a paper/presentation?2. Develop an initial investigation user story. At the end of the sprint, the data scientist should have determined an (1) action plan of next steps to define out more user stories, (2) level of effort for that work, and (3) any dependencies that may exist. Dependencies can include other work, individuals, or data that is needed to continue development.3. Struggling with developing acceptance criteria? Bring the story to the backlog refinement and discuss it with the team as a whole. A discussion around acceptance criteria can help refine the task and make sure the story is well defined before it is brought into a sprint. If you still cannot write acceptance criteria, bring in the stakeholders looking for the work and talking with them.
After you have defined the title, description, and acceptance criteria, the next item to look at is story point estimation. Estimating story points or level of effort can help understand how long a task will take and how much work someone should be taking on that sprint. You can choose to have story points or ignore them. It is up to you. I have tried it both ways and prefer to use story points.
When I am writing or updating user stories, I use story point estimations to define the level of effort and determine how much work a person can take on during a 2–3 week timespan. We use the Fibonacci sequence as a general estimate of time. I believe it is easier to define story points after the story has acceptance criteria. You know the expected outcome that the development team is trying to achieve making it easier to pick points.
Typically, I assign these points during sprint planning or backlog refinement when I have the development team decide how long things will take. This is because a more senior data scientist may say something will take less time than a junior data scientist who may need more time. Once I get everyone’s thoughts, I tend to take either the most common story point number or average them. Meaning, if I have four data scientists and they gave me [5,5,3,5] for story points, I would take 5 as the most common value. But, if they gave me [5,5,2,2], then I would average out to 3 story points.
4. Story points shouldn't be assigned by one person. Sit down with your team and vote on the expected amount of points per each story. You may end up with a range of points; this is when you can average out the work's anticipated length. 5. Research and open-ended tasks can be hard to story point. Write your acceptance criteria first. This will help you and the team know the expected outcome of the work. Then, estimate the level of effort. I tend to pick larger numbers for research tasks as they may require more time to investigate and determine the next steps.6. If something unexpected comes up in the sprint with a user story, it can cause the story to become more points than initially expected. It can happen but don't stress over it. Your data scientist and product owner can do one of two things. (1) Update the story to be more points based on the work, and move other items out of the sprint to the backlog. (2) Note down the next steps in a new user story and plan the additional work in the next sprint. Depending on the work being done, you can choose either. I have done both before, and based the decision on other factors, such as what work is a priority or blocker to others.
After the development team has completed their user stories, the last action to be done is for them present their work in a sprint review. The main takeaway I have seen with sprint reviews is adapting your sprint review to your team’s and stakeholder’s needs. In the last year, our sprint reviews format has changed format a few times to find what works best for us, and that is okay.
It would help if you found a balance between what works best for your team presenting in the sprint review and the stakeholders looking to watch the review. What information are they most interested in seeing? If your data scientists present their demos by delivering PPT presentations instead of showcasing code, then do that! This is your team’s time to showcase what they have done to benefit the stakeholders and customers. Adapt your review to give them the platform to present, take in feedback, and determine the next steps.
7. Demo, Demo, Demo! Demo's are a common aspect of software development teams who want to showcase the new additions to products they have made. In data science, you may not have a web application or product you are creating. Instead, you may have data mining, visualizations, reports, and dashboards of the work you have done. Your demos do not need to be software-based. Commonly, I have seen individuals "demo" a slideshow summarizing their findings and analyses. Adapt your demos to work for your team and stakeholders. This is also an excellent opportunity for data scientists to gain data storytelling skills and communication with people of different backgrounds.8. Understand who your team's stakeholders are and invite them. Your sprint reviews are for them to understand what you are working on and the team projects' status. Stakeholders are the individuals who are impacted by the outcome of your work. They can be engineers, business associates, customer-facing teams, and more.9. The product owner should take down any feedback given by the stakeholders. Note down what is going well or not, mentions or what is a priority, or next steps to take. These items may lead to more in-depth discussions on planning and updating user stories in the backlog.
Scrum may or may not work for your data science team, but if you are looking to try it, know that you can adapt the framework to work for your team’s needs. As you learn the best way to define your own user stories, try adding or removing fields that may not be relevant to you. Experiment with the need for story points, the way you story point, and how you estimate time for your planning work. Consider how you can best define acceptance criteria for everyday tasks your team works on. Make the user story template your own as you learn what works best for your team. As your sprint comes to an end, showcase your work in a sprint review to your stakeholders. Your review can include demos, presentations, and more. Adapt the meeting to be what you and your stakeholders need.
Has your team been using Agile Scrum or another framework? What has worked well for you in planning and road mapping your work?
What is Scrum? by Scrum.org
Agile vs. Scrum by Guru99
What is a Product Owner? by Scrum.org
Atlassian Community and Jira Issue and Project Tracking
If you would like to read more, check out some of my other articles below!