Danube - Hierarchial Requirements and Scrum - Comments

Update

MichaelJames — Thu, 21 Jun 2007 17:43:59 -0500

With the 2.1.0 release, ScrumWorks Pro now allows both n-dimensional groupings (via themes) and more conventional nested hierarchies (via Programs and Groups). Some of our customers have already seized this feature to organize their large backlogs.

I see the need for this even with the relatively simple backlog students create during the CSM courses. Often they'll need to spread Post-It notes across the wall in messy groups and tables before they can cherry pick the highest ROI items as candidates for the first Sprint Backlogs.

No one said being a Product Owner was easy. But the analytics in ScrumWorks Pro can ease the pain in large high-stakes projects.

--mj

Multiple Representations of the Product Backlog

MichaelJames — Tue, 12 Dec 2006 15:01:21 -0600

This opens about 10 different threads which could all lead to interesting discussions. I've been investigating approaches large organizations apply to these challenges and hope to publish my recommendations soon.

Regarding Vic's original point, we feel hierarchies can be useful ways of thinking about requirements but you also need to break free of them when it comes to prioritization. The ScrumWorks theme tagging mechanism allows you to retain those hierarchies even as you reach deep inside them for the juicy (high ROI) bits you need to do right now.

We need a 1-dimensional prioritized transformation when it comes to *scheduling work*. Our ability to apply multiple tags means you can apply as many groupings as you find useful for the complexity of your problem, whether that's a Work Breakdown Structure, a traceback of split epics (megastories) and goals, or a traditional numbered requirements document.

Michael James
Software Process Consultant (who spent years doing aircraft/spacecraft real-time embedded systems thus can appreciate Nick's challenges)
http://www.danube.com

heirarchial requirements

Gregory Smith — Tue, 12 Dec 2006 07:44:53 -0600

Hi Nick;

We too have a large effort where most teams are using scrum. We have a combination of code and content developers aligned into 10 Scrum teams. Much of the functionality we deliver requires coordination across teams and departments. We had Jeff Sutherland come and do some initial ramp up training when we only had 2-3 teams but our efforts have become bigger and more complex. We are struggling with nearly the same array of SOS issues that you call out.

We are experimenting with allowing 1 team with a dedicated PO to be 'point' and having that team in turn act as the PO for constituent teams. This simplifies the points of contact for stakeholders and ensures that constituent teams are delivering needed dependencies to the 'point' team in a sort of hybrid model somewhere between scrum and classic release management. I do not think we have it quite perfected yet but it has been a good excercise and I am liking the over-all direction.

I find it unacceptable for a PO to need to keep track of multiple overlapping teams/sprints and attempt to coordinate the deliveries of multiple teams into cohesive features. It causes additional communications overhead and invites the PO to manage "aka meddle with" team and inter-team dependencies that they should be managing themselves. As a result we're putting together a hierarchical system allowing a high level ticket to be decomposed into sprint backlog items across several teams while maintaining progress/burndown feeders back into the master ticket.

Do you keep an independent blog or any kind of a chronicle of your particular adventures? I am interested in hearing more about the methods you are finding success with.

-G

We use heirarchial requirements

anicoll — Mon, 11 Dec 2006 12:06:02 -0600

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

Hierarchial Requirements and Scrum

VictorSzalvay — Fri, 8 Dec 2006 12:47:00 -0600

As the Product Owner of ScrumWorks, I'm often asked why ScrumWorks does not support hierarchical nesting of backlog items (i.e., user stories, PBIs, etc.). The answer is simple but highlights some profound differences in the way requirements are managed in Scrum and Agile as opposed to other methods.