We are a small team of 6 developers. We usually complete 4 to 5 user stories in a given sprint. Typically every person takes a complete user story and some take a couple of them.

The problem arises when there we need to continue the same user stories in the next sprint. A dev team is willing to work only on the same user story which they have started previously, stating that they know it very well and will finish it easily.

How to keep all developers informed about all user stories? If it is covered during sprint planning meeting then the meeting will take more than a day to discuss everything.

  • 1
    One piece of puzzle that I'm missing in your question: I assume that your team isn't the only one--there are more of them--and planning happens across all the teams, thus the problem with stories unfinished by other teams. Is this correct? Nov 1, 2012 at 17:05
  • @PawelBrodzinski Whatever may be the case, either its other team or a another member from the team. Nov 2, 2012 at 6:00

2 Answers 2


From the business point of view, their reasoning is correct, if one wants to avoid waste created by transportation.

I'm guessing here, but your question might have to do something with cross functional teams. If so, I'd say that there is a difference between a team, which is capable to adapt to new circumstances and deliver, and an individual who knows everything about the product. Scrum is about the first case, it is about a team.

So, if you are concerned that small silos around certain features are about to be built inside your team, you can demonstrate why it is good to share or switch user stories (until it doesn't risk the delivery dates). Here are a couple of reasons:

  • the quality of the feedback is better
  • it is easier to get help with technical issues
  • the integration of the user stories is easier
  • the planning meeting becomes more effective

I suggest to have a retrospective, where you'll try determine the bus factor of the team (how many members should leave the team in order to make the delivery impossible). Take the last Sprint as an example, and pick one team member, and ask the team what would have happened if got removed from the team in the middle of the Sprint? Have a discussion, and put down the findings. Then, pick another member, and do the same. Repeat this until the team concludes that it is impossible to continue Sprint. Collect the findings, and let them figure out how to increase the bus factor by one.


Perhaps I'm missing the point here, but in my experience this is at the core of Scrum:

  1. For starters, it is on the variety of skills that the team finds its strength
  2. It is on the coming together of the minds that better solutions are found, not just nice solutions

I'll try to reverse engineer your question a bit, and then seek to land the answer you might be looking for. I hope.

Allow me to clarify the afore mentioned points a bit further:

Typically every person takes a complete user story

Through such statement—as seen on the context of your question—it seems each member takes on the many aspects of a user story on their own. Such idea puzzles me of course, cause if your team has variety of skills, each user story should be touched by as many hands as needed in order to drive it home safely.

The simplest of user stories might merit the brush of a designer, the pen of a copywriter, the mind of a back-end developer and the expertise of a front-end guru; all skills diversely spread over the members of your team.

Thus, you must be endowed with a powerful squadron of "I can do it all myself" Rambo Developers, who can do design, copy, DB entities, server side and client side code. That, or perhaps you are missing the power of a team: its diversity, and the coming together of each member's strengths.

But that's where the strength of a team lies, not the strength of Agile and Scrum per sé.

If it is covered during sprint planning meeting then the meeting will take more than a day to discuss everything

As stated on my second point, it is by the coming together of many backgrounds, skills and ideas that great solutions come about. The perfect time for them to shine the most is precisely during the planning meetings.

A user story is not the same as a requirement. It is meant to be brief and concise, providing an scenario and a use case with it. It is NOT a recipe or set of instructions; it is a problem, a feature, the seed of something that might be but which hasn't been entirely figured out yet.

A product owner comes and bluntly states: "As a user, I'll like for pictures in my gallery to stop getting stretched out". A simple enough use case, but hardly an statement you can say places the dot atop every "i".

  • An architect might come and fancy a great solution for it; but he is not day in and day out in the code, so he might miss something out in his fancy solution.
  • A tech lead might come and try to use a cannon to kill a mosquito, but that may be a product of being too close to the code day in and day out to lift up his sights and look at a simple enough solution.
  • A designer might not know much about how to code the code, but he knows about pictures.

In my experience, Scrum stands out from the pack because of these brief lapses where the team comes together NOT just to apply a solution, but to dream it up as well.

Rest asure, you are bound to get some resistance trying to convince everyone that it is through these planning meetings that you are going to be saving more time than anything else, especially when they drag for much longer than they are used to. Amongst the first arguments you'll get is: "wouldn't it be better if we spent this time coding and... being productive?" At any rate, I know I did. It was only after they had tried everything else, fallen behind several times, failed to get everybody on the same page, and repeatedly underestimated User Stories, that they came back... this time willing to follow along. After all, they didn't have much else to lose :)

Whenever we have applied Scrum correctly good results have not failed to follow shortly after. Instead of getting burnt for trying to borrow the team's time for a couple of hours, now we might run for 4 hours straight and nobody frowns at it. In their own words: "this is good, there are no surprises anymore; everyone knows what everything is about, what everything is for, and what is expected of them." How so? Well, they took part of the solution. That aided in two fronts at once: being truly productive and keeping them engaged during such long meetings; a true win-win situation.

In Short

Following a Scrum methodology, and taking advantage of the strengths it seeks to foster

  • you won't have a problem with User Stories that spill over to the next sprint, everyone knows what to do and can get on with it right away
  • you won't have a problem transferring over knowledge
  • you won't have a problem keeping all members informed
  • you are likely to spent more time in planning meetings than before
  • you are likely to save you and your team considerable time, misunderstandings and rework by giving up on playing "chinese whispers"
  • instead of one pair of eyes, you'll have many pairs of eyes dotting every i and crossing every t
  • you are likely to get better and faster solutions through many eyes looking from different perspectives than you would otherwise

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.