Why do you need a User story to fit in one sprint?

Dim Blinov
Agile Pies
Published in
8 min readJul 21, 2022

Check out my course about Scrum on Udemy for free https://medium.com/agile-pies/scrum-fundamentals-1-5h-course-on-udemy-for-0-limited-offer-279d03e516cd

This article is also published here https://www.agilealliance.org/why-you-need-your-user-stories-to-fit-into-one-sprint/

Why should a User story fit entirely into one sprint? What are the benefits of having Stories smaller than one iteration? Why should you split bigger User stories? And even more — why divide Stories into even smaller pieces? What is the value of 1/5 sprint Stories?

In general, one or more tasks completed to the DoD state in each sprint allow you to comply with the Scrum principle of incrementality. But what does this mean, and why follow this principle?

Working in increments has many advantages, and a lot of them are listed below. I would like to introduce you 39 reasons why having small User stories is good for your team, your company, your product, your customer, client and users.

Planning and risks

1) By dividing Stories into smaller ones, you automatically conduct a more detailed analysis of the tasks and take into account more nuances.

2) And thereby reduce the risk of failure of the task.

3) And this means that the probability of successful completion of such a task increases.

4) And the task estimation will be more accurate.

5) And also, the smaller size means that you can plan more Stories for iteration.

If, when splitting, you strive for maximum independence of smaller Stories (see the "Independent" characteristic in the list of criteria for good Stories, called INVEST), then:

6) you will be able to implement Stories in the desired order and in different combinations. (And thereby become more adaptive to requests and changes.)
In particular, you will be able to do riskier things earlier.

6a) If dependencies are the biggest risk, then you can implement integrations early, and thereby reduce the number of dependencies on adjacent teams.

6b) If product hypotheses are the riskiest things, then check them in early iterations.

6b) If the riskiest thing is a new technology, then start with it.

Story splitting helps to take riskiest thing first.

Continuing the list of positive consequences of small and maximally independent Stories,

7) If some unforeseen situation occurs, only one Story out of several planned for the sprint would be blocked. Otherwise, the only big one that you barely crammed into the iteration is blocked means the entire scope of the sprint is endangered. Similarly, if changes are needed, they will affect specific small backlog items, rather than one big one entirely, and other tasks will be able to move on.

8) Since independent Stories can be implemented in any order, iteration planning is simplified.

8b) And if in the early iterations you have already implemented integrations with components of other teams, then there will be fewer dependencies and synchronization points, and planning the next iterations will become easier and easier.

8b) There will be more alignment in actions with other people and teams.

8g) The waiting time for other teams to complete work on each story will decrease.

A more accurate forecast and more tasks are implemented per sprint.

9) List items 6–7–8 lead to a reduction of risks-uncertainties on the whole.

10) And together with item #4 about a more accurate estimates, all these lead to a more accurate forecast for the iteration, a more feasible plan.

11) And to the high predictability of the team’s work.

12) And this will allow not only to plan a larger number of smaller tasks (item #5), but also to complete most of the taken Stories.

13) And thus, the probability of success — creating a DoD increment by the end of the iteration — tends to 100%.

As an additional deferred benefit: when the team learns to quickly divide large Stories into small ones, it will be able to easily do this during the sprint, when needed. This is a useful approach, when the team does not have time to implement the whole Story, and is able to quickly divide it in order to have time to implement the more important half.

If you do not have time to make the whole story, then you can decompose during the sprint.

Product and quality

14) The developer remembers the code of the last X hours well. The smaller the task, the better the developer remembers the written code, which means it will search for and fix defects faster.

15) According to Scrum, at the end of the sprint, the Story, like any other element of the backlog, must meet the Definition of Done — the definition of readiness. The team learns to complete each task to the DoD state, rather than hoarding a set of a dozen tasks that are 99% ready.

Items #14 and #15 lead to a better product. (And increase the adaptability/agility of the team.)

16) The team will be able to show the finished Story during the sprint, without waiting for its end, to get comments, and still will have time to adapt the result before the Sprint Review and increment demonstration.

Further, this leads to a product that meets customers and users needs.

17) Small tasks allow you to prioritize more precisely, and thus deliver the most important earlier and postpone the less important (this topic will be developed in #23). Let’s say, you had ABCDE tasks, and you divided A into A1,A2,A3, analyzed priorities, and it turned out that the correct order would be A1,B,C, A2,D,E, and A3 dropped far down the backlog, and thus you saved time and effort, and implemented BCDE earlier.

Prioritize better. If you divide A into A1, A2, A3, it may turn out that the new order would be A1, B, C, A2, D, E, and A3 goes down the backlog.

18) More frequent delivery to the production environment will allow you to get new knowledge more often: check the performance on prod, get early feedback from users.

19) All this helps to go towards a greater product — both corresponding to the customers and users expectations, and high-quality.

20) As a result, the product becomes more economically successful.

Interested parties, customers

Small tasks are performed faster.

21) Customers and users will be able to give their comments on completed tasks during the iteration, and not only during the demonstration at the end of the sprint. (Of course, if their requests jeopardize the Sprint Goal and significantly increases the amount of work, then the query can be placed in the product backlog and postponed until the next sprints.)

22) If the task is brought to the DoD state, and customers are satisfied with the result, then it may be delivered to the production environment earlier — before the end of the sprint, and even several times during the iteration.

23) More precise prioritization (item #17) allows you to follow the Lean principle of reducing overproduction wastes, and one of the 12 principles of the "Manifesto for Agile Software Development" of the art of maximizing the amount of work not done, and thereby save the budget, increasing the RoI of the team’s efforts.

24) Since the team is now more likely to create a modified working version of the product (increment) by the end of each iteration (item #13), during the Sprint Review it demonstrates the real functionality, and not just the reporting slides. (According to Scrum, only DoD results can be demonstrated at the Sprint Review.)

25) And this increases the satisfaction of stakeholders.

26) High predictability (item #11) and stability of the team’s work leads to the fulfillment of promises, and this strengthens the trust of stakeholders and improves relationships.

Users

Frequent and early delivery of value in the form of new ready-made high-quality functionality to the production environment:

27) Allows users to receive value in small portions regularly. And the gradual learning of new features makes exhaustive user training documentation unnecessary.

28) Entails frequent feedback from users.

29) Increases user satisfaction, even if you haven’t delivered everything-everything promised on time. And this further increases the satisfaction of stakeholders (refer back to #25).

30) Allows your business to benefit earlier: additional users, early sales. And, again, the product becomes more economically successful (back to item #20).

Team

31) A large deadline, which usually entails an unbalanced workload and exhaustion of the team in fire-fighting mode during the last quarter of the timeline, is now divided into several smaller, usually 2-week ones. Therefore, the level of destructive stress of team members is reduced.

Bringing several small tasks scheduled for a sprint to the DoD-state (item #12):

32) increases the sense of completion,

33) increases the feeling of high pace, which contributes to strengthening trust with stakeholders (#26),

34) and further, completeness and speed together with predictability and stability (#11), improves team morale.

35) Following the principles of Lean and Agile (#23), the team does not waste time and effort on less important things.

36) Small tasks go through the software development process faster, especially when striving for focus and "One piece flow". (Read Scrum values.) And therefore, the workload of employees during the sprint becomes more balanced by competencies. (The team, of course, strives for interchangeability and T-shaping, but not always at that state from the very beginning.) And it logically follows that the overload of testers and developers at the end of the iteration is lower and happens rarely.

37) A non–overloaded team with a low level of destructive stress is usually a more happy team.

Completing tasks to the DoD-state (#15)
38) makes the team more adaptive to changing priorities and scope of work.

39) A team that delivers some working functionality each and every sprint — maybe not 100% of the plan, but at least part of it, a working one — constantly and regularly, is a hot team. And hot teams create great products.

In conclusion

All in all,

  • more satisfied, adaptive and hot teams
  • that deliver new high-quality DoD-state functionality every 2 weeks or more often
  • receive satisfied users and stakeholders in response, and
  • together they create a great successful products and
  • constitute a sustainable business.

--

--

Agile Pies
Agile Pies

Published in Agile Pies

Ideas and Howtos on Team management, projects and Agile, written simple and useful

Dim Blinov
Dim Blinov

Written by Dim Blinov

DBlinov.com, SkillsCup.com, Agile coach, Soft skills trainer, Personal coach

No responses yet