Should I Split a user story or not and why not?
Albert Arul Prakash Rajendran
?? Dynamic Agile Coach & Transformation Leader | 20+ Years of Experience in Driving Change Across Industries
User story, should be small enough functionality that is vertically sliced and must be able to complete within a sprint
When a development team doesn’t complete user story in an iteration (time box), typically this is one of the most asked questions by the team members to any agile coach or scrum masters. Mostly they would love to split the story by moving the incomplete tasks into new story planned for next sprint.
When it comes to outsourcing scenario with complex contracts that ensures fixed story points per iteration, “how will we track our efforts that's spent?” Or “our payment will be in trouble?” or what will happen to our velocity?
There are zillion articles written from both sides of the table and this is my personal take on it. Love to discuss and learn from all
--------------------------------------------------------------------------
In my personal view, when a user story is not completed in the sprint, I always recommend moving the story back in its entirety to product backlog (or next sprint) based on discussion with product owner. I do not recommend splitting that story into completed and incomplete piece and move the incomplete piece to next sprint.
When we allow team to split the story just before the sprint end, it opens many dysfunctions within the team. Most important one is DISCIPLINE and COMMITMENT. When you split the story, we are invariably sending a signal to the team that, GROOMING is not important, and we can start a story with inadequate details for development. Based on the progress we will later split the story and do rest and will start working towards fixing the velocity chart (many still uses that as a metric to gauge team’s performance).
What will happen to my velocity if we don’t split?
The story point that’s part of the story will be accumulated into next sprint. There is not going to be any loss of story points. In next sprint, you will be completing more story points in less time effort
We will not be paid if we don’t have 95-100% of stories?
Two bytes:
- That’s a wrong way to have a contract. Your higher management must work on different model with the client and not link your velocity with payment terms.
- Even if your contract says so, you are not paid weekly (at least in India). You would be paid only in the month end which means you have two sprints (of two weeks period) in every payment cycle. You will be accumulating the story points anyway in the next sprint.
Sprint is like an examination in a fixed timebox
If we should relate to a real-life activity, a sprint is like an Examination which happens at a fixed time box. Once the time box is completed, the exam invigilator collects your answer sheets and move out. They wouldn’t wait for you to complete writing answers. You cannot request them by saying, I completed 75% of answer, please give me more time or give me 75% mark in this exam and in next I will write the remaining answer and take remaining 25%. You just cannot do that.
If your answer is only 75% and is not complete, in this examination, you will lose the allocated marks for that question (also you can’t get that lost mark in next exam ??).
In order to ensure you have properly sized story that can be completed in a sprint,
- Groom the story well before the sprint start.
- Ensure you do not have lot of unknowns in a story
- Slice the story before the start of sprint to the smallest size.
- Swarm to complete
- A user story can be worked by multiple team members. Please swarm to complete. This will ensure you complete stories quicker and value is generated continuously.
- Do not work on the mode as one team member one story.
- New scope identified in the middle of sprint progress
- Work with product owner about the new scope to move out of sprint
- If scope drastically change current work, work with Product owner again to see what value can be generated. If it doesn’t generate without the added scope, check for possibilities to move out of sprint.
Based on my experience, the teams that allows story splitting at the end of sprint tend to delay the delivery of value and the team that doesn’t split improves their grooming, shared understanding and story completion ratio. Many times, when story is split, over a period, team also moves back to old practice of Serial work (design -> develop -> test) into action
There are chances, the amount of work that’s completed may generate value to customer. In those cases, yes as product owner, you can split the user stories and deliver the value. In my view, these are 0.000001% of cases.
About AgilityCafe:
I am building a community of Agile practitioners & enthusiasts to learn, share knowledge and bring agility to the world. We will be doing webinars, coffee talks and meetups in regular fashion to spread the knowledge.
Just like a café that serves variety of caffeine flavors, friends of AgilityCafe would serve every flavor of agile practices to the world. If you would like to be part of this community, please subscribe by emailing to [email protected]
Engagement Manager at AWS
4 年Scrum masters or Agile coaches who understand how front end is connected with back end technology can help their team to split the stories better. In this example scrum master needs practical knowledge to help development team and not theoretical one.
Founder of EnterpriseJoy - Crafting Organisational Excellence in - Under 5 Hours? ? Principal Consultant at Technogise ? Advisory Board Member ? Blogger, Speaker, Podcaster ? Forever Curious ??
4 年Few questions (and also like to understand what’s your role with this team): 1) I agree that the stories should be sliced well before an iteration, let’s say it wasn’t done well. Now it’s the end of the iteration and the team realises that this story can be split such that what’s completed is of high quality and can be released to create value, will you still hold your team back? Can’t there be another way to teach the team to slice and refine better? Principles to consider: Self organising teams, no one tells the team how to convert requirements into releasable functionality; and working software is the primary measure of progress (velocity shouldn’t be an issue, consider it zero if you like, that’s secondary with some coaching). 2) Why is it necessary to split the story to the “smallest” size? It takes effort to slice, as long as the story is small enough for an iteration, isn’t that sufficient? Principle to consider: The S in INVEST is small, not smallest. Are you suggesting something different?
. Putting a dog here to follow the conversation, brilliant!
Enterprise Agile Trainer & Coach, SPC 4.5, RTE 5.0, SAFe Agilist 4.5,CSM, PSM
4 年Very well explained.
Director-Software Development for CT/AMI at Philips
4 年Beautifully articulated Albert- something we encounter on a daily basis