Slice the peach

 When should you split a user story? Think "when would you slice a fruit?"

  • A banana is big but manageable you'll probably eat it whole. You might want to slice it in certain circumstances.
  • A peach could get messy so i'd rather slice it
  • A kiwi is small but its hairy, i'm definitely slicing that!
Deciding when to slice a user story is not always easy. Often its difficult to apply hard rules. Its usually a balance of size and complexity.

In the above examples, a banana represents a big story that isn't complex, should size alone determine whether to split it? The kiwi represents a story that is small but highly complex, we know its hairy, we know we shouldn't bite straight into it but how to slice it is not obvious either? peel first? slice first?


The peach represents the story I see most often. It represents uncertainty. Once you bite into a peach you discover if it is hard, soft, juicy, extremely juicy! If you slice it up first then you know exactly what you're getting and its much more manageable if things do get messy



Comments

Post a Comment

Popular posts from this blog

Expanded EPIC boards

Image
What's the problem? As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out. Additionally, defining an entire release worth of stories in advance which, ultimately, require change or may
Read more

Things to consider when you want to change from Scrum to Kanban

Image
Scrum or Kanban? A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8% "Scrum doesn't work for us!" I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following: We can't finish anything in a 2 week sprint There are too many meetings Our list of priorities keeps changing We can't plan for 2 weeks.  Our product owner keeps changing his/her mind They often feel like Kanban is a silver bullet because: It doesn't ask you to finish anything in 2 weeks It doesn't im
Read more

Moving beyond tasks

Image
One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks. Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees. How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on their own. I often see tasks such as “Manual QA”, “Code Review”, “Write test cases”, “Database work”, “Front end work”, “Back end work”. People often argue to me that the task breakd
Read more