# Fitting Scrum for Software Development -- Part II

DevFeed: [Fitting Scrum for Software Development -- Part II](<https://devfeed.tech/articles/fitting-scrum-for-software-development-part-ii-23722.md>)

Original publisher: [Read original article](<https://medium.com/booking-com-development/fitting-scrum-for-software-development-part-ii-367045569c9a?source=rss----1c36c35f9c76---4>)

Author: Egor Savochkin

Published: 2025-02-27T14:06:58Z

Content type: tutorial

Language: en

Sources: [Booking.com Development - Medium](<https://devfeed.tech/sources/booking-com-development-medium.md>)

Topics: [Agile](<https://devfeed.tech/topics/agile.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [software-development](<https://devfeed.tech/topics/software-development.md>)

Tags: [agile](<https://devfeed.tech/tags/agile.md>), [development](<https://devfeed.tech/tags/development.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [programming](<https://devfeed.tech/tags/programming.md>), [scrum](<https://devfeed.tech/tags/scrum.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [technology](<https://devfeed.tech/tags/technology.md>)

## AI overview

This article argues that Scrum teams developing software should adapt Scrum while retaining its core principles and integrating strong engineering practices. It focuses on breaking product backlog items into small, value-driven tickets based on acceptance criteria rather than implementation activities, while considering dependencies and clear ticket naming.

## Source excerpt

Scrum, AgileFitting Scrum for Software Development -- Part IIBreak down stories like a boss and a few more trickssource Many software teams use Scrum, but it comes with challenges. While it originated in software development, its creators made it broad enough to work across industries. The idea? Teams should adapt and improve it while sticking to core principles. But in reality, that rarely happens. Instead, teams get stuck in rigid processes, perfecting rituals instead of shaping them to fit their needs. Another big consequence is that Scrum emphasises management but overlooks engineering practices. But without strong engineering foundations, it barely works for software development [Fowler09]. In this series, we adjust Scrum to better fit software development, integrating engineering practices where needed. In the first article, we explored how to make daily stand-ups more efficient -- focusing on blockers and tracking only the tickets that matter. We also advised against breaking backlog items into generic tasks like development, testing, or support. We recommended considering a ticket done only after shipping it to production. That likely raised even more questions. How should we break them down instead? With many small, value-driven tickets, how do we ship them despite dependencies? And how can we name tickets in a way that is clear, avoids confusion, and conveys maximum information? Let's tackle those questions. Break down by acceptance criteria. Earlier we talked about tracking value instead of activities. Sounds great in theory, but in practice? Not so simple. Scrum teams work in time-boxed iterations, usually two weeks long. To fit within a sprint, the team needs to break down PBIs (product backlog items) into smaller pieces. And this is where teams often struggle. The easiest -- and most tempting -- way to split work is by implementation activity. This allows for endless breakdowns, right down to a single line of code. But this approach comes with several prob