I have this problem, a team with 4 members working under scrum, with specific skills each one of them:

  • Person A) DBA with reporting skills
  • Person B) DBA with stored procedure skills and a very deep knowledge of the business
  • Person C) Developer
  • Person D) Tester

Problem 1

Right now, we're at the end of sprint 6, Person A has ran out of tasks, and he wants to start working on sprint 7 issues. I have explained to the whole team that we must focus on finish sprint 6 functionalities, and not to think about independent tasks, but it is not being really accepted. On despite off they team is not working on sprint 7, they're not really convinced about it.

Problem 2

We will have the sprint 7 planning meeting on wednesday, and the team wants to talk separately to the PO in order to ask him questions about the User Stories, Person C argues that listening to "person A" talk with the PO is a waste of time for him, and he prefers to start working in other tasks that he knows he can start working and has enough information

What I understand so far is that the team should not start with tasks belonging to a different sprint because it would lead to lose the focus on the current sprint goal, the whole team should be involved on getting the work done as a team and not as separate members. We're not playing tetris trying to accommodate tasks as if they were shapes that could be arranged, we're delivering a specific set of functionalities.

I want to convince them, but I'm running out of arguments and I need help to get the team back in focus.

Am I wrong about it? Any advice?


1 Answer 1


When we started practicing scrum, we kind of dropped our specialisms and individual projects, instead we started working as one team. While I am more of an expert in Unity3D and C# and we have another team member who is more skilled with Node.js (etc), we ensure that we are spreading the knowledge of the projects.

One thing agile and scrum are in favour of, is spreading knowledge in the team. If you only have one person that can make changes to the database due to their knowledge then what do you do when that person is away and your PO wants you to make changes? As well as this, agile is about keeping things open. If just one person works on a project, you get worse code and a worse project than if all of the team takes part in it.

In scrum, if one team member finishes a task, they pick up another one. By the sounds if it, your team is still stuck trying to manage their own projects and their own tasks. To me this seems to be fighting against what scrum is trying to do for your team.

I.E.: I may not be fantastic at Node.js and it may take me longer, I may even choose to pick up mostly Unity or C# work as I feel more comfortable with it. But if all the tasks in that area are complete and there are still outstanding tasks in the sprint, I pick up what's left. I don't get to just pack up and go home, or start on new backlog issues.

Scrum intentionally spreads the knowledge and stops things being "my project", "his area" or "her task". Everything becomes the "teams", if a task isn't done by the end of the sprint then the team has failed at completing that task. No single individual is responsible for it, everyone is.

I think your team need to get their heads around the idea that every project is the teams project and if there are things to be done, anyone can picks them up. So in this case Person A should be picking up any more out standing tasks still on the sprint. This is also the reason that all persons are involved in sprint planning meetings (for estimation and such). It ensures quality and makes sure that the team is moving as a team.

  • 2
    @FernandoMoyano Change is hard. We experienced the same problems from our managing director when trying to adopt scrum (thankfully all of the developers were well up for it). You need to fully explain the reasons and the ideas behind agile and scrum to help them understand why they are doing things. You cannot simply tell them to change with no reason as to why this is a better idea. Change isn't easy, it takes time but you need to explain reasons, you can't just push change onto people. Dec 23, 2014 at 13:33
  • 1
    When our current lead developer introduced us all to agile properly, he took an entire morning to sit down and explain all of the principles and concepts. Then he explained how we practice those principles using scrum and we all made the decision together to use scrum and see how it goes for us. If you've not taken the time to explain everything objectively then I'd suggest doing that, it's important people know why change is required rather than just actioning it. If you don't explain the reasons then you get resistance due to misunderstanding and poor communication. Dec 23, 2014 at 13:44
  • 4
    @FernandoMoyano: I get the feeling that your developers aren't yet working as a team. One (blunt) way to get them towork more as a team is to make it clear that all tasks in the current sprint are more important than those in future sprints. If someone doesn't have the skill to work on them, then he could still contribute to them by making sure the others aren't distracted from there work. This could go as far as fetching coffee for them. If you make it clear the fetching coffee part is serious, you might find that developer A is also quite capable of executing tests. Dec 23, 2014 at 15:27
  • 1
    +1 @BartvanIngenSchenau. Everything put into the sprint is from the top priority of the backlog. Nothing currently in the backlog should be more important than the stories in the sprint. Dec 23, 2014 at 15:29
  • 1
    Mark Twain "I'm all for progress, it's change I don't care for" Feb 25, 2015 at 13:57

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.