I am part of a 6-developer scrum team and we do sprints of one week.

To be able to get an story in a sprint, we like these stories to be clear-enough (ready) before we start on them. Typically, this is done by having short discussions between the stakeholders and some team members.

However, I found this quote online (https://www.agilebusiness.org/page/ProjectFramework_15_RequirementsandUserStories)

Stories are not a contract. They are “placeholders” for features which the team will discuss and clarify near to the time of development.

I agree on that, in the sense that the development team should be able to implement it in a way the team seems fit.

However, there are some cases where I feel stories slip-by. 3 examples:

  • There are stories that are build by just two team-members and discussion on the solution is not necessarily shared between the team.

  • I sometimes review such code where I think the solution increases technical debt, and that might be caused my an implementation that could have been better if the whole team was involved in the discussions. Or, at least, the members that are interested.

  • Other occasions are when a change is discussed during the stand-up, where some extra requirement pops-up for a story.

Are there any best-practices to hold these discussions with the entire team? Or am I too much involved and should I just focus on the code-itself, not the approach?


The beauty of self organizing teams is that your team gets to decide how to organize the work. If the team feels that a different way of organizing the work is better, the team is free to change the way it organizes itself.

The ideal time to discuss this is during the sprint retrospective, where

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.


The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible.

Onward to your questions:

Are there any best-practices to hold these discussions with the entire team?

There are no practices that are always best, because different teams operate in different circumstances, and may thus have different needs. That's why Scrum gives teams the authority to decide what works for them, in their particular project.

But if the team thinks that these discussions would be better with the entire team present, the team can do that. Just like you decided to hold these discussions with some team members, you can decide to hold them with all team members :-)

Or you could decide to split the discussion, discussing the important things (for some definition of "important" your team would work out) with the entire team, and the details in a smaller meeting.

This way, the entire team would get to consult on the important stuff, while leaving the details in the care of the team members actually doing the work.

Other occasions are when a change is discussed during the stand-up, where some extra requirement pops-up for a story.

That sounds potentially problematic. If the change was important enough to warrant team discussion, it's likely important enough to affect planning the work, and in which case it should have been discussed before the sprint, and possibly with the product owner, who is in charge of cost/feature trade offs. My team would try to identify and then discuss such changes in the backlog refinement meeting, where user stories are estimated, and cost/feature trade offs are made.

Or am I too much involved and should I just focus on the code-itself, not the approach?

On the contrary: Scrum requires team members to look beyond their own work. How else could the team organize itself, and continue to refine its way of working to better match the needs of the project?

  • I like your last paragraph, as this is how I would ideally act. Do you have a source for the statement as well? Jun 17 at 15:25
  • 1
    I already quoted: "The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done" and "The Scrum Team identifies the most helpful changes to improve its effectiveness". At a higher level, this is discussed in the section on Scrum Theory, which writes "If any aspects of a process deviate outside acceptable limits [...] the process being applied [...] must be adjusted".
    – meriton
    Jun 17 at 15:33

What you quoted and what you are saying don't seem to conflict with me. In general, when people say that User Stories are a placeholder for a conversation, they mean between the team and the person asking for the feature.

As far as conversation inside of the team, that is always welcomed by Scrum. Certainly, the team should be discussing backlog items coming into the team at both backlog refinement and Sprint Planning. But nothing says it needs to stop there.

What I'm hearing from you is that the team's process is less than ideal and leading to gas in communication. No big worries, as every team's process has these and there is always room for improvement. The best advise I could give is to raise this in the Retrospective and propose that the team experiment with different ways of resolving these challenges.


The Planning meeting is an opportunity for the whole team to discuss together the stories they plan on doing in the upcoming sprint. They might also take this time to go over each story in detail, perhaps even breaking each one up into concrete tasks. Such an approach helps pool expertise, and can help address the first two examples you give.

Regarding the 3rd example, missed requirements that are noticed somewhere mid-sprint are not typically added to the current sprint, to fight scope creep and to keep estimations on-track. Instead, a new story is created for them, which can be started in the next sprint. (But of course this can depend on how critical the requirement is.) At any rate, a more thorough Planning meeting should reduce the chance of missed requirements in the first place.

  1. Stories built by two team members.

Not your problem. The idea behind SCRUM is not to have the whole team work in committee, and effective teams don't have all the stories reviewed by everyone.

The Product Owner will make sure non-valuable stories are buried, if you step back and let them do their job.

  1. The solution increases technical debt

Technical debt is not the same as additional functionality.

Technical debt is when code is committed that must be manually tested, as it now incurs a cost that is repeated independent of the solution. Technical debt is when a solution is written that is known to require a rewrite, because it is based on obsolete libraries and frameworks.

Added functionality is the project, and the Product Owner prioritizes the addition of functionality by burying the stuff that isn't needed or outright cancelling it.

  1. When a change is discussed during the stand-up, sometimes extra requirement pops-up for a story.

The the story was insufficiently groomed prior to being accepted. This happens, and it's often not a real blocker, but the person reporting it just wants to show off he's working hard. Try to ignore it.

In cases where the issue becomes a real blocker, then the story won't be delivered; and the team takes a measurement hit for accepting a story they couldn't deliver (and failed to detail sufficiently in story grooming).

If a person wants to start detailing the story, a new story to capture the detailing should be created. This "detailing" story should have acceptance criteria to know when it would be done, and should be scored for effort just like all other stories. Taking it on during a sprint is scope creep on the sprint, and this kind of scope creep is often called a "spike". The previous story should be set to a blocked state, and should stay on the sprint as it's part of the sprint's promise of delivery.

This makes the system work well because it is designed to create failures which provide feedback to the team when the team is not effective. In retrospective, with honest accounting of failures, the team should notice that the root cause of the failure was that the story was under-groomed, and that they should take extra care to ensure they don't commit to under-groomed stories without first scheduling a story to improve grooming (or performing grooming during the downtime in the sprint when all other tasks are complete).

  • As I understand, 'Technical debt' is a bit more board, i.e. Tech.debt is also introduced if the code becomes less maintainable as was to be expected by a change, for example, copy-paste-code; poor separation of concerns, etc. It that generally accepted as well? Jun 17 at 15:27
  • I must disagree with "effective teams don't have all the stories reviewed by everyone", because it's implying that my team is "not effective" even though our product owner is happy with our work. Yes, we review every single story in committee when we estimate it. Planning poker is a thing.
    – meriton
    Jun 17 at 15:37
  • 1
    @RobAu Your suggestions are good suggestions, in the cut-and-paste example, the debt is the cost to refactor the code, assuming it shouldn't be cut-and-pated (there are rare corner cases in architecture where cut-and-paste is a conscious choice due to a higher value in separating concerns under certain deployment models, but let's not focus on exceptions). In the separation of concerns, it again depends on the separated vision is detailed enough to be a known entity. If it is not, then it's hard to know the cost of transition to it. Without this, the debt is unknown.
    – Edwin Buck
    Jun 17 at 16:34
  • 1
    @RobAu With an unknown debt, it is easy to assume the benefits of paying it are somehow known, but in reality without the costs being detailed, it is impossible to state that the benefits outweigh the costs. In places where they always believed the benefits outweighed the costs, it led to architectures that requires so much effort that actual progress was difficult. The book "Better, Faster, Lighter Java" is an excellent tool in covering these cases. In many scenarios, unless the costs are quantified, arguing for different approaches can become more opinion than engineering.
    – Edwin Buck
    Jun 17 at 16:38
  • 1
    @EdwinBuck: I did not say we have meeting per work item. I said we have a meeting for reviewing stories. That's a different level of granularity. If you mean "work item", your answer should say "work item", not "story". And I am not sure I agree with the work item part: A team discussion can be an effective way to disseminate knowledge, and it can help discover that team mates have relevant experience, something OP thinks is holding his team back. So I think the ideal degree of detail of team discussions is somewhat situational, which is why I disagree with the absoluteless of your phrasing.
    – meriton
    Jun 17 at 17:01

A very quick couple of suggestions which may help with some of your issues:

  • Refinement meetings - if you are not currently using Sprint Refinement meetings, this could help to spread the knowledge of user stories as well as agree high level technical design.
  • Sprint Planning - these are when you can break user stories into tasks, which again creates visibility of what's being done.
  • Technical refinement meetings - I've also seen teams have regular 'technical refinement' sessions where a champion allocated by the team to each user story presents technical approach back to the team and it's agreed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .