How large stories can impact learning

Hi guys, this week I got inspiration for the post from a conversation that I had with one of my colleagues. I was explaining him the book that I read during my holidays - “Drive“. We went through many topics, but the one we discussed most was about Casual Friday, let me explain what it is.

In case you are not familiar with the term, you can think of it as a relaxed work day, the day when people are already in anticipation of the forthcoming weekend :). In the context of our discussion this pertained to that specific time that Google made popular with its employees: when they can use their time to do whatever they want, of course, within the company activities, but not necessarily related to their on-going projects.

The conversation continued for some time when he suddenly said that he cannot really do that, he does not have time to try this Casual Friday. He then explained that each their iteration takes two weeks, so if he starts using a day per week off the project they will have only eight days left and then they cannot deliver much for that iteration. At first, I could not understand him, so I decided to dig into it…

I asked him, “How come you cannot deliver anything in eight days? How long do you take to finish a story?” However, when he told me that each story usually takes six to seven days, I understood their problem. Of course, if they take seven days to deliver a story and if something happens, say a small delay, it would easily take them the whole iteration to deliver that one story, but they will not have any time for Casual Fridays.

In my humble opinion, they are just accepting too large stories. It would make sense for them to break these large stories into smaller units so that they could have more deliverables at the end of the iteration. Then I suggested that he tries an experiment: they could start creating smaller stories, say two-day stories, and they could see how many stories they would accomplish within the iteration. If everything goes well, they could deliver up to four stories per iteration and still have their Casual Friday.

I cannot promise that this would immediately solve their problems and allow them to have their Casual Friday, but I think they might be one step closer to it, because I truly believe that smaller stories are much better than the large ones.

This was just one example that demonstrated how large stories can have a negative impact on the development work. Here you can find more examples that explain why smaller stories are better for your development process.

What is your opinion about it?

Final3dPostCTA

No Commentsto How large stories can impact learning

  1. hi, totally agree. I only hope that your friend is not implementing an epic instead of a user story. But having a well defined user story normally translates into a 3-4 days code and testing. However, everything depends also in their definition of DONE. If documentation is also included, then it might take some more hours….

  2. Marko says:

    The smaller the story, the higher its priority should be and vice versa. That is, backlog may have big and small stories, but we should accept only smallest stories (with highest priority) into the sprints. Someone has said that team should accept only stories that are size of 1 (i.e. smallest possible). Maybe somthing to improve in groomings?

  3. Hi, Luis!

    I agree that accepting large stories (e.g. epics that have not been broken down to small stories) slows learning. Here are a few reasons off the top of my head:
    * Developers get less experience in starting and finishing work on a story.
    * Developers get fewer opportunities to enjoy the small victories within a sprint that can make working more fun.
    * Large stories require more analysis and trying to understand the code than small stories.
    * Small stories broken down by the Product Owner save much of this analysis time for the Developers, allowing the team to increase velocity.

    I like stories that are 1/2 to 2 days at most. Richard Lawrence posted a great collection of patters for splitting stories, at http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

    -Alan

    • Luis Goncalves says:

      Thank you so much for your comment Alan :). I specially liked this :”Developers get fewer opportunities to enjoy the small victories within a sprint that can make working more fun.” This is so important :)
      Thanks,
      Luis

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>