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.

 
4 favorite thumb_down thumb_up 5 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

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 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Ram Srinivasan
    By Ram Srinivasan  ~  3 years ago
    reply Reply

    I like the topic, but do not like the analogy between comparing/breaking user stories and breaking up from a relationship. Looks cheesy, especially for a professional conference. 

  • Sachin goel
    By Sachin goel  ~  3 years ago
    reply Reply

    Hi - can you pls also share some feedback from this talk on other forums(i see some mentioned in the Link). Guess the question is if this talk is more relevant for begineers or the advanced audience.

    thanks - sachin

  • steve ropa
    By steve ropa  ~  3 years ago
    reply Reply

    wow, that is a lot of interesting material in 90 minutes. I also think that some more detail in what the ten ways are would help a lot.  What about these methods make this advanced?

  • Savita Pahuja
    By Savita Pahuja  ~  3 years ago
    reply Reply

    Hi Dipesh.. Please let us know how your talk is unique .. As all agile practitioners know the art of splitting user stories. 

    Also if you are going to do some hands on so the session would be workshop rather than talk.  Please update your proposal with sufficient information regarding the same.

  • Sonik Chopra
    By Sonik Chopra  ~  3 years ago
    reply Reply

    Hi Dipesh

    THanks for providing details on your proposal. Can you please provide some information on 10 breakup techniques mentioned in your proposal? And how will this benefit the intermediate/advanced audience?

    Regards

    Sonik Chopra

     


  • Liked Naresh Jain
    keyboard_arrow_down

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

    Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Advanced

    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.

  • 45 mins
    Demonstration
    Beginner

    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.

  • Liked Prashant Kutade
    keyboard_arrow_down

    How should be a Sprint Retrospective ?

    45 mins
    Experience Report
    Beginner

    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
    IBM
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    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.

  • Liked Shrawan Gaur
    keyboard_arrow_down

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

    45 mins
    Talk
    Beginner

    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.