Team Pushing Back on Smaller User Stories Because Of Testing + Code Merging
Hey guys,
I'm a pretty new PO and the team is struggling to break down user stories in a meaningful way and would rather just work on very large stories that end up being carried over to following sprints. Scrum would say to break them down so that they are more digestible, but I am getting pushback because of having to "re-test" scenarios from previous stories. I'm aware of the INVEST framework, but we seem to be having trouble using it in practice.
Here's an example:
[EPIC X ] A feature where we will be building and item list which will later be quoted in a subsequent feature.
For Epic X:
-[User story 1] We should be able to add quote line items which are populated from our "product list" in a dropdown
-[User story 2] This product drop down should have an auto-complete search which filters the contents of the dropdown based on what is being typed in.
-[ User story 3] The act of adding the first line item should expose an additional 2 fields.
-[User story 4] User should be able to "publish" their work, which triggers a status change on the quote list.
So the team pushed back on this break down stating that executing it in this manner would cause us to have to re-run all tests from previous user stories and thus we would be wasting time. Furthermore that having multiple team members taking on stories for the same feature is inefficient and will cause issues when merging code. They would instead prefer to tackle all these features in one story and have only one team member work on this.
So my question here is, are we breaking it down in a way that doesn't make sense? Are we testing in a way that doesn't make sense? Are we developing in a way that doesn't make sense?
Any insight is really appreciated! Thanks in advance.
Let's put the woodpile to one side for the moment along with the matter of how it gets sawn up.
Are the team meeting their Sprint Goals, and delivering immediately usable increments of work at least once per Sprint? As Product Owner, do you think the Sprint Goals you negotiate with them are good ones?
@Ian Mitchell's question is the first thing I would ask. If the answer to that is "no", then the team needs to address that in a way that they feel is right for the team. There is no correct answer to how the work should be done but there is a correct reason for doing the work.
Who broke the Epic down into those stories? Was it you? If so, I see that as your first opportunity to improve. The Product Owner should not be telling the Developers how to work. You should be providing the issue that needs to be addressed and the people doing the work (i.e. Developers) will break the issue into workable units. I will say that the solution they offer has never worked for any team I have worked with. They are advocating for a group of individuals that work in their own world and no interaction is done. This is not a team. The benefit of having a team of like minded, like talented people is that you can work together on things to make them better.
As a person with over 20 years of Quality Assurance background, I don't agree with their assessment of having to rerun all the tests. You only have to rerun tests if you change behavior of previous code. And it is quite possible to deliver increments of a solution without having to retest. It takes some effort to scope the work correctly but it is possible to do.
And while I have your attention, I'm going to mention a pet peeve of mine. Problem statements never use the word "should" as you illustrated. That implies that "this is the behavior we want but it's ok if it doesn't happen". Should is a probability expression. Problem statements state the behavior that is wanted. The word "will" makes it clear.
I often see developers, scrum masters and product owners become obsessed with stories and sizing. Does it matter? Isn't the goal to create a product with valuable features which will make the customer happy and the business a profit? Think about the end result and work your way back. Everything else is noise.
The line below triggered me.
So the team pushed back on this break down stating that executing it in this manner would cause us to have to re-run all tests from previous user stories.
This is something I would discuss in the next retrospective it looks like testing is something that is holding the team back to make releasing increments regularly difficult and see what can be done to make this easier.