Adding more User Stories just to keep Developers busy

Hi Pablo,


Not sure if I understand the whole situation correctly. My understanding is that during the Sprint the Dev Team adds user stories to Sprint Backlog based on high priority items in Product Backlog while other stories are not done just to make sure every developer is 100% utilized?

If my assumption is the case here, I would say the following might be true:
1. the Team needs coaching regarding Sprint planning - if the Team still under commits after they have been working for quite some time (6months) perhaps it would be a good idea to make them aware of their velocity (calculated based on 100% done user stories) during past sprints
2. the Team needs some coaching regarding helping each other and working together to get user stories done. Example: the Team selected user stories A,B,C,D for the Sprint and at some point A,B,C are done and they say they would like to pull E,F while one person (Joe) works on finishing up D. Perhaps it would be good to ask them if they think there's anything they could do to help Joe complete D?


Maybe my assumption above was wrong and your Dev Team 'invent' user stories without discussion with PO and add them to the Sprint?
Please let me know more about the situation and I will try to help.


Michal

Hi Michal,

Thanks for your reply.
Your assumption is correct. Let me give you a concrete example:
The team consists of 4 developers which are 1 senior and 3 junior developers. The senior developer is have been working for the company since the beginning so knows the technology and domain which they are in. The 3 other developers are all relatively new, so no technology and domain knowledge.

Because of this, (as a result of the retrospectives) we as team have added an explicit “Review” column so that the senior developer can review all the implemented code.
Now the team pulled User Story A, B, C and D into the Sprint and while we are still in the middle of the Sprint the team “finished” the tasks of Story A, B and C. The Story isn’t completed (yet) because they are all still in Review mode. (the column that the team introduce to limit bugs and optimize quality) So to finish the Stories the Senior Developer needs to do all review.
What should the other 3 developers do now? Story C isn’t big enough for 3 Developers to work on. This is the moment where usually the PO, CTO, manager comes in and talk about being effective and having 3 developers doing nothing is NOT effective.

I usually play it strict and say “sorry, let’s first finish every story before we pull in more work”. Because this way we don’t lose focus and who knows perhaps there needs to be some refactored after reviewing.

What would you do?

> What would you do?

1. Ask the team... "How can we solve this challenge?" Have you asked?
2. How long has the team been doing Scrum? i.e. What is their level of Scrum knowledge? Are they Shu, Ha, or Ri?

I like Charles' response. It seems to me like the best you can do is discuss this in the team. My first thought is that your team feels responsible for their work, and wants to avoid wasting time doing nothing. In a sense, they're trying to optimize by picking up new work on their own volition.

But maybe their strategy is not such a good idea. Scope is fixed good reasons in Scrum, after all. It might actually break down the sense of being a team and being responsible together for delivering the functionality agreed on at the start of the sprint.

It seems to me like the best thing you can do is help the team work together more. That's often difficult. Some developers like to work on their own. They believe they are faster and more efficient that way. And sometimes they are. Or they feel that there is too much time pressure to 'share the burden'. But if they help other developers grow into their own jobs, the team as a whole will benefit greatly. Pair programming is a good approach. We do this a lot at our company; developers that cannot really join in, pair up with another developer and work on the code together. This might seem inefficient, but it's like having a real-time debugger sitting next to you :)

Hi Pablo

Scrum does not distinguish between senior developers and developers. There should be no skill silos and the team should be thoroughly cross-trained. In the example you give, the senior developer has become a bottle neck because only that person is doing reviews. Having a "review" column is fine, but any team member should be able to review another's work. The members of a Scrum team should go to where the work is, and collaborate to get work-in-hand completed before bringing new work in.

I have had success with giving developers stories that I knew they would finish in a sprint, along with additional stories that they could start if they finished early (or the first story was blocked for some reason). Knowing that these second stories would not be completely done and would be finished in the next sprint. This was in a regulatory environment that had a higher rigor of integration testing (done by system testing team, not developers) and more rigorous code reviews that created bottlenecks to having stories finished. It's probably not "pure scrum", and it takes discipline to make sure developers are truly getting the first stories as far along as they can before moving on to the next story, so that they aren't tempted to do "fun stories" instead of "hard stories", and it was very much environment specific (different areas of the product needed vastly different skill sets, with embedded developers, algorithm experts, etc.), but it worked, and kept all developers fully utilized. It also depends on how you are doing integration. I assume you aren't doing continuous integration, since the stories have to be reviewed before being finished.

I also think pairing people up with the senior developer to do the reviews to increase their level of experience would be useful. The sooner that the reviews can be done away with the better, unless they're required for some other reason besides checking work of less experienced developers.

This is a bit of a hybrid scrum / kanbanish but it's more important to have quality software than to be doing scrum exactly to the book.

Let’s pretend this is the current scenario. What would you guys do?

- A Scrum team of 4 developers.
o 1 Senior Developer who have the technology and domain knowledge.
o 3 Junior Developers fresh out of school.
- The team is in Sprint 3.
- The Senior Developer noticed that, although the 3 junior developers are helping out implementing the Stories, their code quality is really weak. Think of things like bad code practises, unnecessary classes, basically most of the implementations are not durable solutions. Due to this the team added an extra REVIEW column.
- The Senior Developer is owner of the REVIEW column because the 3 other Developers can’t review each other’s work due to lack of knowledge.
- Sprint 3 includes User Story A, B, C and D.
- We’re halfway the Sprint and the team has completed Story A and B
- Story C consist of 1 task and that task is in the REVIEW column.
- Story D consist of 2 tasks. Story D has been estimated as very complex. The 2 tasks is so complex that the junior Developers can’t work on it. Screw this up, and you’ll have an operational escalation. (something dramatic!)
- All summed up: you have 3 Junior Developers currently “idle” and all the pressure on the Senior Developer to finish Story C and D.
What would you do as Scrum Master/ Coach?

> - The team is in Sprint 3.

Does this mean the team has only been doing Scrum for 3 sprints? What's the Scrum maturity of the team?

Who tests these stories?

That is correct. The team (organisation) is relatively new with Scrum.
The stories are tested by the Developers (when implementing the tasks) and by our PO when each stories are done.

Pablo,

While it is always helpful to consult the Dev Team on issues like this, respecting their self organization, it can also be helpful if the SM suggests some possible solutions.

In a coaching situation, and as someone who is a professional Scrum coach, I'd like to see you and your team come up with some possible solutions. I also get the distinct impression that you have some possible solutions in mind and you're looking to validate them against the advice given here.

So, would you be willing to share your ideas so far on how to solve?

I don't have a particular solution right now. That's why I'm posting it here.
I usually tell the team to finish all Stories before pulling more work. But I most say, I slowly doubt it this is the best way.

The given scenario is just an example and I'm curious in the solutions you guys have in mind. Purely from a coach / Scrum Master perspective.

Hi,

By looking at the date the question is posted, I may be late but I would like to comment anyway.

It is great that you have removed an impediment by adding a review column and it resulted showing another impediment in the team. As another person commented, your lead developer is the bottleneck and s/he needs help.

I agree that it is better if the team comes up with a solution so that they own it but if there is no suggestion or the suggestions don't work then you can simply try to suggest some solutions as well.

What I would do is to get the junior members get trained.

You can do it by pairing them. If a senior and junior member paired up and finished a task then the others can do the review. If two junior members did the task then you can facilitate a review session where other junior members and senior member review all together. Senior member should explain the code to the others and why s/he thinks that code has to change.

I would run this 3 sprints and then make the team responsible of reviewing each other's work. You should remove the review task from the senior developer and sometimes it is ok to deliver some stories with technical debts. Involve the PO to check the story asap and if s/he is fine with it the so be it.

Never forget that what a senior developer says is not always the best solution.

Cheers,

Gokce

I got a question for the group: If another story is added to the Sprint to keep the Devs busy, but they don't succeed to finish it before ending the Sprint, how can the Team keep track and don't waste the effort and coding that has already been done?

> If another story is added to the Sprint to keep the Devs busy, but
> they don't succeed to finish it before ending the Sprint, how can
> the Team keep track and don't waste the effort and coding that
> has already been done?

Any undone work should be discussed in the Sprint Review; any work that was done should be demonstrated for possible inclusion in the increment. The undone work can then be added to the Product Backlog so the Product Owner can prioritize it accordingly.

Usually undone work is carried over into the next Sprint, but this shouldn't be automatic. The right process is to add it to the Product Backlog, where the PO might choose to prioritize it into a different Sprint altogether, or decide not to deliver it at all.

Thanks again Ian!

Hey Pablo, I know that this post was over a year ago, so things will have moved on, but I would like to guide others who see this and have a similar problem. My recommendation would be to try to find a solution to the bottleneck first. Someone suggested asking the junior devs (rightly, someone pointed out that Scrum doesn't distinguish between roles) to help, but I'd be tempted to get the experienced dev to focus less on churning out features, and more on helping the newbies to get up-to-speed on the code base so that they can help review each other. Also, with less feature-work, the experienced person can check the less experienced devs' code.

Can you tell us how it played out for you?

Gokce's suggestion is really good, and I'd add another point: I'd encourage the developers to make Coding Dojos. This is a great way to spread knowlegde and train the team on best practices, clean code, problem solving.