Breaking up User Stories can sometimes be as painful as a relationship break up - but it does not have to be like that!

Our experience has shown us that the key to getting full benefit from introducing Agile is in how the project work is broken up. When it gets difficult to see how to write small enough user stories, teams often resort to technical story cards. While this can give the team visibility of the work that is being done, the business is not seeing potentially implementable product, or early delivery of business value.

This talk will dig a lot deeper to expose the real reasons for splitting up user stories and not just talk about doing it as a good practice - we must BE Agile not just DO Agile!

Using real-world examples, this talk will also offer a set of guidelines and some unconventional ways for breaking up larger chunks of work into valuable user stories that can help Agile teams become more successful.


Outline/Structure of the Talk

This talk is conducted in a fast paced, highly-interactive style to keep the audience engaged throughout. Light-hearted humor is used to make the analogy between relationship break ups and user story break ups. 


Mechanics of the presentation

-          Introduction and setting the scene – Why are break ups so difficult? (10 mins)

-          The perfect User Story – is there such a thing? (10 mins)

-          Breaking up - a set of guidelines to follow when breaking up larger chunks of work (epics) into valuable user stories. Dipesh will be drawing upon his extensive Agile experience to share his learning’s and use real-world examples of user stories to illustrate how this is done. (50mins*)

-          Conclusion: Call to Action to break up! (5 mins)

-          Q & A (10 mins) May even challenge the audience to come up with large Users Stories that are unbreakable!

* More details on the 50 min section: One format that has worked really well for this presentation in the past is breaking up the core section of this talk into 3 segments (with 2 ‘commercial breaks’ in between). During these 2 ‘breaks’, the session is turned into an open-forum kind of style where a couple of seed questions are planted to encourage some insightful discussions. A couple of example questions are ‘When is the best time to break up?’ or ‘Who should initiate a break up?’. These sorts of questions get the audience really excited. These discussions are lead to become a nice segue into the next segment.

Also, as the presentation title says, there will be 10 break-up techniques covered during the talk – 3 of which will be done with audience participation. These will be treated as exercise for the audience. The mechanics of this will be is really simple regardless of the size of the audience.

In addition to that, there are several other opportunities for audience interactions throughout the presentation.

Learning Outcome

Dipesh will be drawing upon his Agile experience to share his learning’s and use real case studies and examples of user stories to illustrate the following:

  • Understanding that making stories smaller may be the least important part of splitting up stories
  • Anti-patterns to look out for when trying to break up user stories
  • Knowing when NOT to break up user stories
  • A set of guidelines and some unconventional ways to follow when breaking up larger features / epics into valuable user stories
  • How to ensure that it can all still be put together after the break up
  • How to convert the most common ‘Excuses’ into ‘Opportunities’ to break up user stories.

Target Audience

This talk will be packed with practical examples and real life stories well targeted towards beginner and intermediate levels. This talk is suitable for anyone who is or wants to be working in an Agile team.

schedule Submitted 7 years ago

Public Feedback

    • Naresh Jain

      Naresh Jain - Scaling XP Practices inside your organization using Train-the-Trainer Model

      Naresh Jain
      Naresh Jain
      schedule 7 years ago
      Sold Out!
      90 Mins

      How do you effectively scale skill-based, quality training across your organization?

      Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

      The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

    • Johannes Brodwall

      Johannes Brodwall / Niruka Ruhunage - Remote Pair Programming

      45 Mins

      Can you maintain agile engineering practices with a distributed team?

      Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

      In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

      After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

    • Prashant Kutade

      Prashant Kutade - How should be a Sprint Retrospective ?

      45 Mins
      Experience Report

      Sprint Retrospective

      Sprint Retrospective is a meeting that happens at the end of each Sprint that usually occurs after the Sprint Review. This practice involves the Scrum Master and the team members to discuss what went right and what went wrong in the practices adopted during the Sprint. Thus, it allows modify some practices to maximize the positive and avoid negative points. This meeting provides a moment for greater interaction among the members and allows the team to self evaluate and propose the necessary changes, thereby strengthening the sense of teamwork.

      Like the other meetings in Agile, the Sprint Retrospective requires many adjustments. In the experience reported in one of the Sprint Retrospective in John Deere TCI(Pune, 2013), someproblems that were faced related with the presence of all members at the meeting and related with the tool support. The first trouble was to find a time when everyone could attend, since this meeting was initially scheduled one day after the Sprint Review. The solution was to hold the meeting after the Sprint Review and limit the maximum duration for two hours, so this is not tiring. The second difficulty is the need for multiple tools for holding the meeting, the techniques to be followed to drive the meeting and raise the positive and negative suggestions, as well as project management tool like Rally for presenting data from the project’s progress, such as the Product Burndown.

      Despite the importance of the presence of all team members in the Scrum meetings, in some situations, for example, a project with many distributed teams, a remote meeting with all members becomes impractical which should be avoided. Thus, for those situations, this proposed approach suggested to do a Sprint Retrospective by team, and saving the information collected at each meeting. This information collected should be shared to all members, allowing them to analyze the improvements suggested by other teams.

      One last modification is to hold a meeting among each Scrum Master, similar with Scrum of Scrums, to discuss the Sprint Retrospective done by each team, and with that, it is possible to align the dependency among them. This meeting may occur the day after the Sprint Retrospective of the teams, and it is crucial that each Scrum Master considers the points raised by other teams before the meeting between them, in order to optimize its duration.

    • Dipesh Pala
      Dipesh Pala
      Agile Leader - Asia Pacific
      schedule 7 years ago
      Sold Out!
      45 Mins

      Once upon a time, Martians and Venusians met, had happy relationships together and accepted their differences to work towards delivering a project. Then came Agile and amnesia set in! ScrumMasters and Product Owners forgot they were from different planets. All of a sudden, Product Owners, ScrumMasters and the team members found themselves sitting around a table discussing user stories and potential solutions.

      This unprecedented access and communication created a whole new set of challenges… Sometimes it feels like our team members are from different planets, as if one is from Mars and the other is from Venus. You may have heard of Mars and Venus in the bedroom but this presentation will be talking about Mars and Venus in the team room.

      Based on my many years of experience in coaching and working with people in these roles, this presentation will describe why and how ScrumMasters and Product Owners react differently to various situations in a team room. The key is in understanding how ScrumMasters and Product Owners think and operate.

      And if ScrumMasters and Product Owners are from different planets, does it make sense for the two roles to be performed by the same person? Or does every Agile team even need both of these roles? Attend this talk to find out!

      This talk will further explore how we can counteract the differences in the communication, the emotional and the business needs of the two roles, and tips and techniques to promote a greater understanding between these two of the most important roles in any Agile team.

    • Shrawan Gaur

      Shrawan Gaur - Learn from Mistakes, Retain Your Strong Holds: Sprint Retro: Do As WE Do at John Deere

      45 Mins

      As the 12th Agile Principle states : "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.", it is quite easy to understand the importance of continuous evolvement which involves retaining learning and corrective actions.

      John Deere has started its Agile journey in year 2010 and since then has gone through various phases of transformation. Scrum teams has learnt alot and are continuously learning. Retrospection is one of very important scrum ceremony which paves path for team to advance in right direction.

      Here, I will demonstrate some retro techinques and its applications according to sprint work.