Project-Management | Democratizing Data

Machine Learning Project and Scrum

Fri, 02 May 2025 15:49:17 -0700

I’ve worked on several machine learning projects, and intuitively, I’ve felt that Scrum doesn’t seem well-suited for machine learning. However, during an internal discussion, a colleague said, “If we use Technical Stories, we should be able to break down tasks to fit within two weeks for any tasks. And if we do that, we should be able to deliver value in two weeks for ML products.” I couldn’t properly counter this, so I’m writing this article to articulate my thoughts, including how others in the world are approaching this.

Disclaimer

I have extensive experience in ML but is not particularly knowledgeable about Scrum, having only participated in a few projects as a development member.

Research Method

Brainstorming with Gemini 2.5 Pro (experimental)
- Chat Log (Japanese)
Investigating experiences mainly on Reddit

Anticipated Challenges

Iterative development invariably occurs in ML projects. This is especially true because exploratory phases (EDA and model development) are always involved, and these phases generally involve rework.

I’ve always felt a strong incompatibility between these high-probability rework for ML tasks and the “deliver customer value in two weeks” sprint.

Using Technical Stories

What exactly are Technical Stories? I looked into it, and the example at the beginning of the following article resonated with me.

Feature Injection and handling technical stories

As a developer, I want an automated build So that I can be sure my code works.

I’ve actually seen stories like this here and there.

However, the article above, when considering where the business benefit (which I understand to be synonymous with customer value) lies, argues for the following template to ensure business value and incorporate features:

In order to will need .

Further refining this leads to:

In order to As a I want to <do something, or use or be restricted by some feature>.

In order to stop bots from spamming the site As a member of the commercial team, I want users to fill in a captcha box.

Happy ending? Really?

Business Value in ML Projects

The business value in ML projects and ML products remains providing something that positively impacts customers.

Achieving a model with good accuracy doesn’t immediately deliver customer value; it’s only when the prediction results can be served in the actual production environment that value is delivered to the customer. Alternatively, it might involve summarizing analysis results based on predictions and presenting actionable proposals in a report.

Conversely, I find it quite difficult to deliver such customer value with tickets spanning a few days to two weeks. Often, when a model is being developed, the deployment environment might not even exist yet.

One direction, as Gemini suggests, is to consider “risk reduction and uncertainty reduction as sprint goals.” While not direct customer value, there is certainly business value. Gaining insights like “this feature seems effective for prediction” or “this algorithm was unsuitable for this problem” is valuable in itself. That sounds reasonable.

However, by reading Agile Data Science with R, I got a hint for the question of “Why it’s difficult to fit ML tasks into two weeks?”.

Differences in Task-Level Development Flow

5.1 Linear and Circular Tasks compares the task progression in typical software development versus ML development based on the following diagrams.

It states that while task progression is linear at the task level in traditional software development, tasks in ML projects are often cyclical. (The following diagrams are both quoted from Agile Data Science with R)

Linear tasks in traditional software development are also said to be “completion-oriented” tasks, where the goal is simply to complete the project.

Of course, ML projects also have linear tasks similar to traditional software development, such as data ingestion pipelines, basic preprocessing, developing demo applications with streamlit, and developing prediction APIs.

On the other hand, exploratory and experimental tasks are cyclical processes that involve repeating data understanding, hypothesis formulation, and verification. What’s difficult is that within a two-week sprint, there’s no guarantee of improved prediction accuracy, so nothing can be committed.

How to Implement Scrum in ML Projects

So, what should we do? Even so, some might be thinking, “Top-down, we’ve been told to do two-week sprints, so how do we implement it?”

Looking at several discussions on Reddit, I found the following two approaches:

1. Stop Using Scrum and Use Kanban

This might sound blunt, but adopting Scrum as the workflow isn’t mandatory for agile development.

“Agile Data Science with R” points this out in 3.3 Scrum vs Kanban:

Both methodologies are applied with great success and it’s important to keep in mind that they are a means to an end, not religions. The Agile values and principles should be the primary guideline and when selecting one of the workflows you do so because it is the best way to work in an Agile way because its the best fit for the given situation.

The point is that Scrum or Kanban isn’t a matter of religions; what’s important is for the team to choose the best option to achieve their goals and to monitor whether it remains the best fit.

The author’s company initially adopted Scrum due to the many experienced Scrum practitioners, but it didn’t work well for model development, and they eventually moved to Kanban (12.3 Moving to Kanban).

The reasons cited include that Scrum is too rigid and lacks flexibility for exploratory and experimental phases. Also, as mentioned earlier, it’s impossible to commit to model prediction performance improvements without seeing the data. Therefore, there’s a suggestion that time boxing is better than using story points.

Scoping for data science is then not just estimating how long a task will take to complete, it is also time boxing. If used in this way, the scoping should be done in time units, not in a subjective measure such as story points. The data scientist should not take longer for the task than the team agreed upfront, wrapping up even when he does not feel completely finished.

Since Data Scientists tend to continue experimenting until they are satisfied, setting time limits rather than strict completion criteria is more rational in the research phase.

In practice, they seem to have adopted a Kanban board with the following six lanes. However, for some tasks, they ended up stopping after confirming that the model accuracy didn’t improve during the hypothesis testing phase.

to do
test hypothesis
code review hypothesis
update model
code review update model
done

A very similar point (use Kanban, do time boxing) can be found on Reddit.

Don’t confuse agility with solely scrum and its sprints, which are the root of the problem and work poorly in research mode.

This specific example is easy to understand:

Example: build a PoC in a week. If AUC exceeds X then it’s promising and let’s spend another 3 months on further extensions (data, features, architecture, hyperopt) and putting all into production. If there was no AUC gain on the last week, we do not extend any further. Inside this 3 month time box - execute pure Kanban, task by task, which allows you to take different paths as needed (agility), not waiting till your sprint finishes in 3 days. You already know your new feature is poorly designed and you need to start on tweaking it right now.

In other words, time-box, test hypotheses within that time, and if successful, decide to continue further extensions.

Another key point the author of “Agile Data Science with R” proposes is to quickly create an MVM (Minimum Viable Model) instead of an MVP. For example, initially deploy a simple model like linear regression to a limited set of users as an MVM, then add features, and finally deploy a more complex model (Random Forest is mentioned in the text, but now a NN-based approach might also be considered).

This connects with the idea of time-boxing mentioned earlier. Using an MVM as a hook is a good idea as part of an effort to prune the numerous options and find a high-probability path.

2. Use Hypothesis Based Stories (Modifying Scrum)

Another Reddit thread discussed an approach that mixes Scrum and Kanban. They use Scrum for long-term projects and time boxing for research tasks.

Specifically, they seem to have made the following changes to Scrum:

hypothesis based stories (instead of user based)
foregoe stand ups, people keep their tickets as research logs and @ people when they need help. - Product owner can read the tickets if they want to know where we are
monthly retro rather than per scrum, wider focus
tickets largely written by the data scientists then priorities by product owner

Skip stand-ups and have people keep research logs in their tickets, mentioning others in the tickets when they need help. The Product Owner can proactively check the tickets for updates. Data scientists largely write the tickets, and the Product Owner prioritizes them. The goal is to allow DS/MLE to focus on their work.

Hypothesis Based Stories are particularly unique. If we recall the discussion about business value in Technical Stories, the business value in the hypothesis testing phase of ML can only be described as “reducing risk and uncertainty.” Also, by making “formulating and testing a hypothesis” the goal of a ticket, it creates an awareness of the need to formulate proper hypotheses, and the outcome can be closed as “hypothesis was correct/incorrect.”

The point is that the exit criteria is provable and the delivery is typically the proof. Likewise, disapproving the hypothesis is still a success, we learned something.

Here are some examples of such stories:

“We believe a fine tuned distilbert architectures will allow us to identify cases with a precision of greater than .95 and a recall of greater than .7.”

“We believe it should be possible to transform a given article within our dataset to our standardised form without additional datasets or augmentation”

“We believe x metric can best be explained to stakeholders using a combination of shap values and distribution charts”

Aside: What Does a Product Owner Do in ML Projects?

As an aside, there’s a detailed chapter on what a Product Owner does if they don’t create tickets (5.6 The Product Owner Role).

In summary:

Takes on all communication with stakeholders, allowing DS/MLE to focus on tasks.
Helps discuss and organize the tasks created by DS/MLE through scoping.
Prioritizes the tasks created by DS/MLE.
Points out business concerns that DS/MLE might not be aware of.

Reading this, I feel like the time of DS/MLE is considered more valuable than that of SWE.

Conclusion

After a quick investigation, I’ve reached the following conclusions:

Strict Scrum is not suitable for ML projects.
If possible, separate workflows for research/exploration phases and development phases.
In the research/exploration phase, use time limits instead of story points.
In the research/exploration phase, proceed based on hypothesis testing (write Hypothesis Based Stories, use Kanban).

The idea of time boxing and progressing research tasks centered around hypothesis testing, while common sense in ML projects, is a very powerful support.

So, in response to the initial statement, “If we use Technical Stories, we should be able to break down tasks to fit within two weeks. And if we do that, we should be able to deliver value in two weeks,” my reply would be:

Understand business value as “reducing uncertainty.”
Use Hypothesis Based Stories instead of Technical Stories, or Kanban.
Instead of setting concrete goals within a two-week timeframe, quickly iterate through possibilities by setting time limits.

機械学習プロジェクトとスクラム

Fri, 02 May 2025 13:43:50 -0700

機械学習プロジェクトをいくつかこなしてきたが、直感的にはスクラムが機械学習に向いていなさそうというのを思っていた。が、社内で議論をしたときに「Technical Storyを使えばタスクを2週間に収まるように分割できるはず。そして、それをすれば2週間で価値がでるはず」と言われて、ちゃんと反論ができなかったので世の中ではどういう取り組みがあるのかも含めて、言語化するためにこの記事を書いている。

disclaimer

著者はMLの経験は長いが、別にスクラムに詳しいわけではなく、開発メンバーとしていくつかのプロジェクトに参加したことがある程度である。

調査方法

Gemini 2.5 Pro (experimental)とブレスト
- チャットログ
Redditを中心に体験談を調査

想定していた課題

MLプロジェクトでは、iterativeな開発が必ず発生する。これは特に途中で探索的なフェーズ（EDAやモデル開発）が必ず挟まり、総じてそれらのフェーズは手戻りが発生する。

こうした手戻りが高確率で発生するのに対して、「2週間で顧客価値を出す」sprintとの相性はすこぶる悪いと思っていた。

Technical Storyを使う

Technical Storyとはなんぞや。色々と調べてみたけれど、この記事の冒頭の例がしっくりくる。

Feature Injection and handling technical stories

As a developer, I want an automated build So that I can be sure my code works.

実際にこういうstoryをちらほら見かける。

なのだけど、上記の記事ではビジネス価値（business benefit, 顧客価値と同義だと認識している）はどこにあるのか？ということを考えたときに、以下のようなテンプレートに落とし込んでビジネス価値を確保し、またfeatureを埋め込めばよい、という主張である。

In order to will need .

これを経由して、さらにブラッシュアップするとこうなる。

In order to As a I want to <do something, or use or be restricted by some feature>.

In order to stop bots from spamming the site As a member of the commercial team, I want users to fill in a captcha box.

めでたしめでたし。本当に？

MLプロジェクトにおけるビジネス価値

MLプロジェクト、およびMLプロダクトにおけるビジネス価値は、顧客に何かしらの良い影響を与える何かを提供することであることには変わりない。

何か良い精度のモデルが学習できたら、即時顧客価値が提供されるわけではなく、実際の本番環境に予測結果をサービングできるようにして、初めて顧客に価値を届けることができる。あるいは、予測結果をもとにした分析結果をまとめて、アクショナブルな提案をレポートにまとめてプレゼンすることかもしれない。

翻って、こうした顧客価値を数日～2週間のチケットで提供できるか？というと結構難しいと思っている。往々にして、モデルを開発しているタイミングでは、デプロイ先がなかったりすることもある。

一つの方向性としては、Geminiが言うように「リスク削減や不確実性の低減をsprintゴールとする」という発想である。直接的な顧客価値ではないが、ビジネス価値はたしかにある。「この特徴量が予測に効きそうだ」とか「このアルゴリズムはこの問題には不適当だった」などの知見を得られただけでも価値はある。そう考えるのである。

しかし、なぜ2週間にフィットさせるのが難しいのか？こうした疑問にヒントを与えてくれたのが、Agile Data Science with Rだった。

タスクレベルの開発フローの違い

5.1 Linear and Circular Tasksでは、以下のような図をもとに、典型的なソフトウェア開発と、MLでの開発のタスクの進み方を比較している。

曰く、従来型のソフトウェア開発では、タスクレベルで見れば、タスクの進行が直線的であるのに対し、MLプロジェクトではタスクが循環的であることが多い。（以下の図はともにAgile Data Science with Rから引用）

従来型のソフトウェア開発での直線的なタスクは、言い換えるとプロジェクトを完了させればよい「完了型」のタスクだとも言われている。

もちろん、MLプロジェクトでも従来型のソフトウェア開発のような直線的なタスクもある。例えば、データインジェスチョンパイプラインや基本的な前処理、デモ用のstreamlitでのアプリ開発、予測用のAPI開発などである。

一方で、探索的・実験的なタスクは、データ理解・仮説立案・検証という作業を繰り返す循環型のプロセスである。何が難しいのか。2週間のsprintの中で、予測精度が向上する保証はないので何もコミットができないのである。

MLプロジェクトでのスクラムを実践する方法

ではどうするのか？そうは言ってもトップダウンで2 week sprintが降りてきたから、どのように実践していくかを考える必要がある、という方もいるかもしれない。

Redditでの議論をいくつか眺めていると、以下の2つのアプローチがあった。

1. スクラムをやめてKanbanを使う

いきなり身もふたもない話であるが、agileな開発をするのに何もスクラムをworkflowとして採用するのが必須ではない。

Agile Data Science with Rでも3.3 Scrum vs Kanbanでこういった指摘がされている。

Both methodologies are applied with great success and it’s important to keep in mind that they are a means to an end, not religions. The Agile values and principles should be the primary guideline and when selecting one of the workflows you do so because it is the best way to work in an Agile way because its the best fit for the given situation.

ScrumかKanbanかは信仰ではなく、目的を達成するためにチームが最適なもの選び、それが最適かをモニターするのが大事、という指摘である。

著者の会社では、スクラム経験豊富な人も多かったため当初スクラム採用したが、モデル開発でうまくいかなくなり、結局Kanbanに移行したという話がある(12.3 Moving to Kanban)。

理由としては、スクラムは厳格すぎて探索的・実験的フェーズでは柔軟性が低いことがあげられている。またデータも見ないで性能向上にコミットもできないのは先述した通り。そのため、story pointをつけるよりtime boxingの方ががいいという指摘がある。

Scoping for data science is then not just estimating how long a task will take to complete, it is also time boxing. If used in this way, the scoping should be done in time units, not in a subjective measure such as story points. The data scientist should not take longer for the task than the team agreed upfront, wrapping up even when he does not feel completely finished.

DSは納得いくまで実験をし続ける傾向にあるので、終了条件を厳密に決めるより、時間で区切った方が良いというのは研究フェーズでは合理的である。

実際には、以下のような6つのレーンを持つKanbanを採用したようである。ただし、いくつかのタスクでは仮説検証段階でモデルの精度が上がらないことを確認して終了することもあったそうだ。

to do
test hypothesis
code review hypothesis
update model
code review update model
done

まったく同様の指摘（Kanbanを使え、time boxingをしろ）はRedditでも見られる。

Don’t confuse agility with solely scrum and its sprints, which are the root of the problem and work poorly in research mode.

この具体例なんかはわかりやすい。

Example: build a PoC in a week. If AUC exceeds X then it’s promising and let’s spend another 3 months on further extensions (data, features, architecture, hyperopt) and putting all into production. If there was no AUC gain on the last week, we do not extend any further. Inside this 3 month time box - execute pure Kanban, task by task, which allows you to take different paths as needed (agility), not waiting till your sprint finishes in 3 days. You already know your new feature is poorly designed and you need to start on tweaking it right now.

つまり、time-boxingをして、その中で仮説検証をしてうまくいったら続きをやる、という意思決定をしていくのである。

また、もう一つのポイントとして、MVPの代わりにMVM (Minimum Viable Model)をさっさと作ること、というのを Agile Data Science with Rの著者は提案している。例えば、最初は線形回帰などのシンプルなモデルを限定したユーザーにMVMとしてデプロイ、次いで特徴量を追加し、最後により複雑なモデル(本文中ではRandom Forestが挙げられていたが今ならNNベースのアプローチもあるだろう)をデプロイする、というような流れである。

これは先のtime-boxingとの話ともつながるが、無数の選択肢の中から確度の高い道を探して枝刈りする取り組みの一つとして、MVMをフックにするのはいいアイデアだと思う。

2. Hypothesis Based Storyを使う（スクラムに手を入れる）

別のRedditのスレッドでは、スクラムとKanbanを組み合わせるというアプローチがあった。長期的なプロジェクトではスクラムを採用し、リサーチタスクではtime boxingを使用しているというものである。

特に、スクラムに対して以下のような変更をしたようだ。

hypothesis based stories (instead of user based)
foregoe stand ups, people keep their tickets as research logs and @ people when they need help. - Product owner can read the tickets if they want to know where we are
monthly retro rather than per scrum, wider focus
tickets largely written by the data scientists then priorities by product owner

仮説ベースのstoryを書く。スタンドアップをやらないで、チケットにリサーチログを書く。手助けがいるときはチケットでメンションする。Product Ownerは自分から情報を取りに行く。チケットはデータサイエンティストが書いて、優先順位はProduct Ownerがつける。つまり、DS/MLEに自分の仕事に集中してもらう、ということである。

特に、Hypothesis Based Storyはユニークである。なぜなら、先ほどのTechnical Storyにビジネス価値の話を思い返すと、MLにおける仮説検証フェーズでのビジネス価値は「リスクを低減する、不確実性を下げる」としか書きようがないからである。また、「仮説を立てて検証をする」こと自体をチケットのゴールにすることで、「ちゃんとした仮説を立てないといけない」という意識が生まれ、結果は「仮説が正しかった/間違っていた」ということでcloseできる。

The point is that the exit criteria is provable and the delivery is typically the proof. Likewise, disapproving the hypothesis is still a success, we learned something.

storyの例も併せて紹介しておこう。

“We believe a fine tuned distilbert architectures will allow us to identify cases with a precision of greater than .95 and a recall of greater than .7.”

“We believe it should be possible to transform a given article within our dataset to our standardised form without additional datasets or augmentation”

“We believe x metric can best be explained to stakeholders using a combination of shap values and distribution charts”

余談: MLプロジェクトでProduct Ownerは何をするのか

余談ではあるが、Product Ownerがチケットを作らないのであれば何をするのか、ということについて詳しく書かれた章がある。(5.6 The Product Owner Role)[https://edwinth.github.io/ADSwR/a-methodology-for-agile-data-science.html#the-product-owner-role]

まとめると

Stake holderとのコミュニケーションを一手に引き受ける。DS/MLEにはタスクにfocusしてもらう
DS/MLEの作ったタスクについて議論をしてscopingを通じて整理をするのを手伝う
DS/MLEの作ったタスクを優先順位付けする
DS/MLEの気づかないビジネス側の懸念点を指摘する

といったところである。

読んでいると、DS/MLEの時間はSWEよりも価値が高いように書かれているように感じる。

まとめ

ざっと調査してみたが、以下のような結論に至った。

厳格なスクラムはMLプロジェクトには向いていない
研究・探索フェーズと開発フェーズでworkflowを分ける
研究・探索フェーズでは、story pointではなく時間で区切る
研究・探索フェーズでは仮説検証を軸に進める（Hypothesis Based Storyを書く、Kanbanを使う）

time boxingの考え方と仮説検証を中心に調査タスクを進めていくというのは、MLプロジェクトにおいては当たり前であるが非常に強力なサポートとなるだろう。

では、冒頭の「Technical Storyを使えばタスクを2週間に収まるように分割できるはず。そして、それをすれば2週間で価値がでるはず」という言葉に対する返答としては、

ビジネス価値は「不確実性の低減」という理解をする
Technical StoryよりもHypothesis Based Storyを使うか、Kanbanに移行する
2週間という枠で具体的なゴールを決めるよりも、時間で区切って可能性の枝刈りを素早く回していく

ということになるだろう。