I'm working as a manager of the software department in our small sized company (~50 people). I have three development teams, 3-4 members in each. One of the members in each team is in the role of the team leader. One of the teams is mainly working an a single project and it happens rarely what they have to help out somewhere else. The other two teams work on 2-3 projects (same for both teams).

My predecessor used no scrum or such, basically he just assigned work very loosely in a daily to weekly rhythm. Of course that lead to the absence of any project planning/controlling artifacts or processes. Nobody ever knew that could happen in the next time and nobody could predict when any task will be completed. You can imagine how the projects run.

I'll have the task to move on from here and I decided to start implementing scrum into the teams. Of course I'm still very unsure about some things and I'm in need for some advice from people which traveled a similarly road much farther yet.

The roles:

  • We have custom driven project with classic project managers and project engineers. Since they act already like product owners, I think best would be to keep that. Would you agree?

  • We have also some intern R&D like projects to improve our products or dev tools on our own. All kind of people can propose or push-start such projects. I usually manage them from start to end. I would be in the role of the product owner for them. Do you do the same?

  • Management of the collaboration and control of the different Teams. That is one of the main things the company does pay me for. I think of implementing a thing like scrum of scrums between me and the team leaders. I would be in the role of the scrum master here, which may or may not bite with the product owner role described above. Would you recommend it to me?

The procedures and artifacts:
I want to start slowly, making sure everyone is following on our path.

  • The things I want to begin with is maintenance of release- and sprint-backlogs capturing user stories, sprint planning with cutting the stories into tasks and maintaining task boards, and daily stand ups.
    If that works I would go on introducing estimations, burn down charts, measurement of development velocity.
    Afterwards maybe measuring developers individual estimation optimistic-factors to improve project finishing forecasts.
    Would you agree to that sequence or do something else?

  • The thing causing me the most head aches for now is how to do all that while working on different projects at the same time inside a matrix organization.
    The backlog: Should I have a single one capturing all stories for all projects? That would probably lead to complicated sprint planning.
    Or better a single backlog for each project? But how would I capture priorities between different projects then? For example story a of project 1 is most important, then comes story 1+2+3 of project 2 and then story 2 of project 1 and so on.

  • As hard as the above is the imagination of the sprint plannings for me. Teams should pull stories from the backlog. But how should they do that if several backlogs would exist and the priorities are going zig-zag between them?

The last two points confuses me most, but I would have to solve them before being able to do even the first step.

1 Answer 1


It sounds like you're asking the right questions and thinking in a reasonable way. As a coach, a couple things jump out as concerns for me:

  • The small size of the teams isn't always a good fit for Scrum. You might consider merging the second or third teams into a single team.
  • You'll need to work with the owners to ensure that a single backlog exists for the teams to draw from, despite being from difference projects. This prioritization process is very hard at first, but is critical for the teams to have a fair chance of meeting their commitments. This is why Scrum recommends a single product owner... the team needs to trust the single voice.
  • Consider using different colored sticky notes or a tag in your electronic tool to indicate which project the work is coming from. This should help with your recognition problems after planning.

Next, just try it... it will work somewhat, but not perfectly, and then you can work with the teams to make it better. This is why the retrospective is so important in Scrum.

If, after giving it a fair trial and pushing hard for a few months, you're still not feeling it work well, you may consider trying out kanban, which seems to work better in environments where there's a lot of requests coming from different directions.

  • 1
    Thank you for you inspiration Eric. I share you concern regarding team sizes. Unfortunately I can't merge them, because then I would have to degrade one of the team leaders. He would earn less money than before and probably quit or keeping back any motivation in the future. That's that "real-world" stands for in the title of my topic. I'll follow you proposal regarding using a single backlog. I unable to come up with anything else making sense. I feel that (my/the) role of the scrum master becomes much more important if there are multiple owners. Jul 4, 2011 at 12:50
  • 1 - Why do you have to degrade a team leader? Can you make them peers and allow them to share ownership of the team? Pair-leadership is remarkably powerful in practice and allows people to actually take time off when in a leadership position ;) Jul 4, 2011 at 19:56
  • 2 - A single backlog is very critical, and not much else makes sense. That said, you should also consider identifying a single product owner that "owns" the backlog and is responsible for coordinating the needs of the various products so that the team has a single voice they can trust for decisions. Jul 4, 2011 at 19:58
  • 1 - It works exactly like that in practice in opposite to the paper :) Jul 6, 2011 at 8:39
  • 2 - I agree, I am already that person. (I am happy to accept your answer and I like it much. Unfortunately I need more reputation points for the up-vote. I will have to postpone it, sorry) Jul 6, 2011 at 8:42

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.