Moving a large organization with 275 developers spread around the world who are maintaining and improving an 11.5MLoC embedded real-time application to Scrum requires levels of coordination that we think we are creating from scratch as no books, consultants (we've hired Ken Schwaber and others) or tools we've reviewed go into detail about the issues we face. Yes, we use hierarchial requirements: Goals, User Stories and Action Requests.

We have Goals that are received from many sources ranging from new features actual paying customers want to infrastructure repair work. With many customers world wide using our equipment in ways we never dreamed possible we have corporate departments working to find the nuggets in the barrage of feature requests that will give the most value to our best paying customers. Our Engineering System Managers add infrastructure improvement Goals to both spackle over past sins and move us to where a system can be built and at least 'smoke' tested in less than two to three days. Our Management and Marketing teams priorize Goals. Our Product Owner Proxies work those issues to prioritize User Stories with the teams. The contention for prioritization is a constant on many levels. The twenty two Scrum teams have to work from one database that holds the Goals as well as the User Stories so we can meet both internal (to the tools team) requirements of giving a single view of all work being accomplished looking down and smaller more discrete views to those working at prioritizing long lists during each team's sprint planning meetings and using those lists during the sprint. ARs are units of work (changes) added to the code base. We use Themes on top of this hierarchy to group work that takes many goals, user stories and sprints to accomplish such as adding a new family of devices.

We are migrating our tools from our current set because we can find nothing that meets the complex needs of a large organization trying to do Scrum. We are creating new processes around the Scrum of Scrums because we can find no literature or help from anyone who has faced the same issues of coordinating so much work before.

Is the Scrum of Scrums its own team? Are the members the ScrumMasters or representatives from each team? Does it have a ScrumMaster? Are the POPs pigs or chickens in the SoS? Is its product backlog the cross-team barriers and coordination issues (we think it is, right now)? Who is the SoS's Product Owner (currently a wide open question)? Our SoS's product backlog varies constantly and requires a significant amount of work by a large number of people; how is this to be factored in at the sprint planning meetings?

Nick Nicoll
DocuSP Problem System Admin