Breaking down user stories, start finishing and stop starting!

Francisco Cobos 🐢
TravelgateX
Published in
3 min readMay 30, 2017

--

Breaking down user stories hasten customer ROI

Sometimes is very hard to make teams to fully understand the concept of breaking down user stories and how helpful it is. This is not easy at the beginning but it is quite good to help you finishing your work. Breaking down into smaller parts is key. By breaking down your tasks you can start delivering smaller portions that will start giving value to customers.

“Stop starting and start finishing”

Some teams make one BIG user story forgeting most of the Agile Principles. Prety sure you won’t be able to finish such a complex user story in just one sprint. So why not breaking it down in smaller parts, and start finishing your work?

Teams must be aware that a sprint planning is a “compromise” with the customer, and the compromise begins when we get together in the Sprint Planning, we agree on what will add value to our customers and how long will take to be delivered.

“Is there any reason to include user stories that you will not finish during the sprint?”

There are different things that may impede you to advance or finish your work. You have the chance to identify such things during your Sprint Retrospective, the Scrum Master must help to stop those impediments and help the team to improve their capability to estimate and to prioritize by knowing the “art” of breaking down user stories.

Estimating gets more easy when you start breaking down user stories. The team will also experiment the feeling of movement and achieving, while customer starts getting ROI.

As an example, imagine a team of five members, you have a BIG or complex User Story that is technically possible to break down into five elements or components.

You can do two things:

a) Assign one portion or component to each team member and finish the job in just one sprint

b) One team member can do the whole User Story in two or three sprints constantly delivering small portions on each sprint.

“When prioritizing, sometimes is more important to know “What you shouldn’t than what you have to do”.

Priority is key. Is the feature needed ASAP?: Break down and split among team members. It is not a priority?: Assign to one team member within a couple of sprints. In any case, breaking down User Stories will even allow you to assist a team member when due date gets closer, you can even redistribute tasks among other team members in a very simple and agile way.

Remember, working software and constant delivering is the measure of progress. Delivering small portions is better than waiting to deliver big stacks. Constant delivering of small portions boost quality too, is more easy to ensure the quality of a small portion (testing) and take quick actions.

Last but not least, I have been using the word priority and not priories. There are not such things as priorities, you only have one priority and you work on each one at a time”. Prioritizing means working on what it matters to give proper return of investment to our customers.

Hope you find this post useful, please give us your feedback 😊

Francisco Cobos

Agile Coach — XMLTravelgate

--

--

Passioned by the learning process, always with positivity, half a philosopher, hungry for challenges and determined, embracing change and all its advantages. 🤘