Category Archives: Requirements

Strategies for Capturing Non-Functional Requirements


Agile modeling

Non-functional requirements, also known as quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues.  The following diagram, which overviews architectural views and concerns, provides a great source of NFR types (the list of concerns).  Good sources for NFRs include your enterprise architects and operations staff, although any stakeholder is a potential source for NFRs.

Architecture Views and Concerns

Why Are NFRs Important?

Stakeholders will describe non-functional requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope.  Considering NFRs early in the lifecycle is important because:

  1. NFRs drive important architecture decisions. When you are identifying your initial technical strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
  2. NFRs will drive some aspects of your test strategy. Because NFRs tend to be cross-cutting, and because the tend to drive important aspects of your architecture, they tend to drive important aspects of your test strategy.  For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.
  3. NFRs will drive acceptance criteria for functional requirements (such as stories).  are typically system-wide thus they apply to many, and sometimes all of your functional requirements.  Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfills its overall quality goals, including applicable NFRs.  This is particularly true with life-critical and mission-critical solutions.

Explore Initial Scope


Capturing NFRs

As you can see in the goal diagram above, there are three basic strategies, which can be combined, for capturing NFRs:

  1. Technical stories.  A technical story is a documentation strategy where the NFR is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the NFR equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
  2. Acceptance criteria for individual functional requirements.  Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria.  Many of these acceptance criterions will reflect NFRs specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”.  So in effect NFRs are implemented because they become part of your “done” criteria.
  3. Explicit list.  Capture NFRs separately from your work item list in a separate artifact.  This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements.  In the Unified Process this artifact was called a supplementary specification.

Of course a fourth option would be to not capture NFRs at all.  In theory I suppose this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders.  This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).

Related Resources

Update: Address Changing Stakeholder Needs


Just wanted to share a quick FYI with you.  We recently updated the Address Changing Stakeholder Needs goal diagram:

Address Changing Stakeholder Needs

The changes were straight forward:

  • We added On-site customer to Stakeholder Interaction with Team.  This is a practice from XP.  As an aside, Agile Modeling’s Active Stakeholder Participation practice is an extension of On-Site Customer (which is likely why we had forgotten to include On-Site Customer as a practice, our bad).
  • We added Interviews to Elicit Requirements.
  • In Elicit Requirements we renamed Look-ahead modeling to Look-ahead modeling/Backlog refinement to include the Scrum terminology.

In all, just a few small incremental improvements!

Update: Explore Initial Scope

UpdateWe’ve updated the goal diagram for Explore Initial Scope, an Inception Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Explore Initial Scope
We made the following changes to the diagram:

  1. Renamed several process factors so that they would start with a verb.  For example, Level of Detail was renamed Choose the Level of Detail.  This is basically a style issue that we will be applying going forward.
  2. The biggest change is that we split the factor View Types into Explore Usage, Explore the Domain, Explore the ProcessExplore User Interface (UI) Needs, and Explore General Requirements.  We want to make the model type options clear as many people found View Types to be too abstract of a concept.
  3. We reworked the options for Apply Modeling Strategy to be clearer – Informal modeling sessions became Agile modeling (informal) sessions and Formal Modeling Sessions became Joint Application Requirements (JAR) sessions.
  4. In Choose the Level of Detail the “None” option was reworded to “No Models” to a make this more explicit.

The Previous Version of the Goal Diagram

Explore Initial Scope

User Stories For Data Warehouse/Business Intelligence: A Disciplined Agile Approach

Database drum

For teams that are applying agile strategies to Data Warehouse (DW)/Business Intelligence (BI) development is it fairly common for them to take a Disciplined Agile (DA) Approach to DW/BI due to DA’s robustness.  A common question that comes up is how do you write user stories for DW/BI solutions?  Here are our experiences.

First, user stories should focus on business value.  In general, your stories should answer the question “What value is being provided to the user of this solution?”  In the case of a DW/BI solution, they should identify what question the DW/BI solution could help someone to answer, or what business decision the solution could support.  So “As a Bank Manager I would like the Customer Summary Report” or “Get Customer data from CustDB17 and TradeDB” would both be poorly written user stories because they’re not focused on business value.  However, “As a Bank Manager I would like to know what services a given customer currently have with BigBankCo so that I can identify what to upsell them” is.  The solution to implement that story may require you to create the Customer Summary Report (or there may be better ways at getting at that information) and it may require you to get data from CustDB17 and TradeDB (and other sources perhaps).

Here are some examples of user stories for a University DW/BI solution:

  • As a Professor I would like to analyze the current grades of my students so that I can adjust the difficulty of future tests and assignments
  • As a Student I would like to know the drop out rates by course and professor from previous years to determine the likely difficulty of my course choices
  • As a Registrar I would like to know the rate of enrollments within a class over time to determine the popularity of them
  • As a Student I would like to know the estimated travel time between back-to-back classes so that I can determine whether I can make it to class on time

Second, user stories on their own aren’t sufficient.  User stories/epics are only one view into your requirements, albeit an important one.  You’ll also want to explore the domain (e.g. do some data modelling), the user interface (e.g. explore what reports should look like), the business process (e.g. what are the overall business process(es) supported by your DW/BI solution), and technical views (e.g. how does the data flow through your solution architecture).

Third, data requirements are best addressed by domain modelling.  As you are exploring the requirements for your DW/BI solution you will hear about data-oriented requirements.  So capture them in your domain model as those sorts of details emerge over time.  Consider reading Agile/Evolutionary Data Modeling: From Domain Modeling to Physical Data Modeling for a detailed discussion of this topic.

Fourth, technology issues are best captured in architecture models.  You will also hear about existing legacy data sources and in general you will need to capture the architecture of your DW/BI solution.  This sort of information is best captured in architecture models, not in stories.

A few more thoughts:

  1. User stories are only one option for usage modelling.  There are several ways that we can explore usage, user stories/epics are just one way.  You could also create light-weight use cases, usage scenarios, or personas to name a few strategies.
  2. Take a usage-driven approach.  The primary modelling artifact on a Disciplined Agile DW/BI team is the usage model (e.g. your user stories) not the data model.  Data modelling is a secondary consideration compared with usage modelling, and this can be a difficult concept for experienced DW/BI professionals to come to terms with.
  3. Keep your initial modelling light-weight.  The agile rules still apply to DW/BI solutions – keep your modelling efforts sufficient for the task at hand and no more.
  4. Get trained in this.  This is a complex topic.  If you’re interested in training, we suggest that you consider DA 210: Disciplined Agile Data Warehouse (DW)/Business Intelligence (BI) Workshop.

Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams


Like it or not, functional dependencies occur between requirements.  This can happen for many reasons, as we discussed in Managing Requirements Dependencies Between Teams, and there are several strategies for resolving such dependencies.  In this blog posting we explore what happens when a functional dependency between two requirements exists AND one requirement is implemented by an agile/lean team and another by a traditional/waterfall team.

In our example requirement X depends on requirement Y.  Neither requirement has been implemented yet (if requirement Y had already been implemented, and better yet deployed into production, the point would be moot).  When we refer to the “agile team” this team may be following any one of the lifecycles supported by DAD (Basic/Agile, Advanced/Lean, Continuous Delivery, or Exploratory/Lean Startup).


Scenario 1: An Agile/Lean Team Depends on a Traditional Team

In this scenario X is being implemented by an agile team and Y is being implemented by a traditional team.  From the point of view of the agile team, this is very risky for the following reasons:

  1. The traditional team is likely working on a longer time frame.  Disciplined agile teams produce a potentially consumable solution (potentially shippable software in Scrum parlance) on a regular basis, at least every few weeks.  A traditional team typically delivers a working solution over a much longer time frame, often measured in quarters.  The implication is that because Y is being developed by a traditional team it may be many months until it is available, compared to several weeks if it was being developed by an agile team.  This potentially adds schedule risk to the agile team.
  2. The traditional team may not make their deadline.  According to the Standish Group’s Chaos Report, the average traditional team comes it at almost twice their original estimate (e.g. a project originally estimated at 6 months of work takes almost a year).  Similarly, the December 2010 State of the IT Union survey found that traditional teams were much more likely than agile teams to miss their deadlines.  By having a dependency on the deliverable of a traditional team, an agile team effectively increases their schedule risk.
  3. The traditional team may struggle to deliver something that is “agile friendly”.  Agile teams routinely develop well written, high-quality software that is supported by a robust regression test suite and where needed concise supporting documentation.  Although traditional teams can also choose to deliver similar artifacts very often their code isn’t as well supported by regression tests and their documentation may be overly detailed (and thereby more likely to be out of date and difficult to maintain).  In other words, there is potential for quality risk being injected into the agile team.
  4. The traditional team may not deliver.  There is always the risk that the traditional team doesn’t implement Y, traditional teams often need to reduce the scope of their deliveries in order to meet their commitments, or if they do implement Y it is done too late to be useful any more.


There are several strategies the agile team may decide to take:

  1. Negotiate a delivery date with the traditional team. Once the agile team has identified the dependency they should collaborate with the traditional team to determine the implementation schedule for Y.  The agile team now has a release/schedule dependency on the traditional team which is a risk and should be treated as such.  The agile team’s high-level release plan should show a dependency on the delivery of Y and their risk log (if they have one) should also capture this risk.  The agile team should stay in contact with the traditional team throughout construction to monitor the progress of the development of Y.  The agile team should also attempt to negotiate early delivery of Y so that they may integrate with it, and test appropriately, as soon as possible.
  2. Collaborate to develop Y.  One way for the agile team to make it attractive for the traditional team to implement Y earlier than they normally would is to pitch in and help to do the work.
  3. Rework X to remove the dependency.  One of the general strategies discussed in Managing Requirements Dependencies Between Teams was to rework X so that it no longer depended on Y.  This may mean that you reduce the scope of X or it may mean that you deliver part of X now and wait to deliver the rest of X once Y is available.
  4. Reschedule the implementation of X.  Another general strategy is to deprioritize X and implement it after Y is eventually deployed.  This is a realistic option if Y is about to be implemented soon, say in the next few months, but often unrealistic otherwise.
  5. Implement Y.  When the lead time is substantial, the agile team may choose to do the work themselves to implement the functionality.  This can be viable when the agile team has the skills, experience, and resources to do the work.  This strategy runs the risk of Y being implemented twice, once by each team, potentially inconsistently.  To avoid this sort of waste the agile team will want to negotiate with the traditional team to take the work over from them.


Scenario 2: A Traditional Team Depends on an Agile/Lean Team

In this scenario X is being implemented by a traditional team and Y by an agile team.  From the point of view of the traditional team, this might be seen as risky for the following reasons:

  1. They may not understand how a disciplined agile team actually works. Many traditional teams are still concerned about the way that they believe agile teams work.  This is often because they perceive agile to be undisciplined or ad-hoc in nature, when the exact opposite is true.  The implication is that the agile team will need to describe to the traditional team how they work, why they work that way, and describe the types of deliverables they will produce.
  2. They may want traditional deliverables from the agile team.  Disciplined agile teams will produce high quality code, a regression test suite for that code, and concise supporting documentation.  Traditional teams may believe that they also want detailed requirements and design specifications, not realizing that the tests produced by the agile team can be considered as executable specifications for the production code.  The implication is that the two teams will need to negotiate what the exact deliverable(s) will be.
  3. They may struggle with any changes to the interface.  Agile teams are used to working in an evolutionary manner where the requirements, design, and implementation change over time.   Traditional teams, on the other hand, will often strive to define the requirements and design up front, baseline them, and then avoid or prevent change to them from that point onwards.  These different mindsets towards change can cause anxiety within the traditional team, the implication being that the agile team may need to be a bit more strict than they usually would be when it comes to embracing change.

The fact is that scenario 2, a traditional team relying on a disciplined agile team, is very likely an order of magnitude less risky than the opposite (scenario 1).   Either scenario will prove to be a learning experience for the two teams, particularly the one that relies on the other team.  Going into the situation with an open mind and a respectful strategy will greatly increase the chance that you’ll work together effectively.


Managing Requirements Dependencies Between Agile and Lean Teams

agile lean

Sometimes functional dependencies occur between requirements that are being implemented by different teams.  For example, requirement X depends on requirement Y and X is being worked on by team A and Y is being worked on by team B.  This generally isn’t a problem when requirement Y is implemented before requirement X, is a bit of an annoyance if they’re being implemented in parallel (the two teams will need to coordinate their work), and an issue if X is being implemented before Y.  For the rest of this posting we will assume that X depends on Y, X is just about to be implemented, and Y has not yet been implemented.  Previously in Managing Dependencies in Agile Teams we discussed strategies for addressing such dependencies, including reordering the work or mocking out the functionality to be provided by Y.  In this posting we explore the implications of managing requirements dependencies between an agile team and a lean team.

Managing requirements dependencies between an agile and lean team is similar to that of managing dependencies between two agile teams, although there are important nuances.  These nuances stem from differences in the ways that agile and lean teams manage their work.  Figure 1 depicts how agile teams do so, organizing work items (including requirements) as a prioritized stack (called a product backlog in Scrum).  Work is pulled off the stack in batches that reflect the amount of work they can do in a single iteration/sprint.  With agile teams the entire stack is prioritized using the same strategy, Scrum teams will prioritize by business value but disciplined agile teams are more likely to consider a combination of business value and risk. Figure 2 shows that lean teams manage their work as an options pool, pulling one work item out of the pool at a time.  Lean teams will prioritize work items on a just in time (JIT) basis, determining which work is the highest priority at the point in time that they pull the work into their process.  As you can see in Figure 2, they will consider a variety of factors when determining what work is the most important right now.

Figure 1. Agile work management strategy.

Work Item List


Figure 2. Lean work management strategy.

Work Item Pool


When an agile team depends on a lean team challenge is relatively straightforward.  Because lean teams take on work in very small batches, one item at a time, it gives them much more granular control over when they implement something.  As long as the agile team lets them know in a timely manner that the functionality needs to be implemented it shouldn’t be a problem.  For example, if the agile team is disciplined enough to do look-ahead modelling (an aspect of Scrum’s backlog grooming efforts) then they should be able to identify an iteration or two in advance that they have a dependency on the lean team.  At that point the product owner of the agile team should talk with the appropriate person(s) on the lean team to let them know about the dependency so that the lean team can prioritize that work appropriately (perhaps treat it as something to be expedited).

When a lean team depends on an agile team it’s a bit harder, but not much, to address.  This time the challenge is with the batch sizes of the work that the teams take in.  The lean team is taking in work in a very granular manner, one at a time, whereas the agile team is taking in work in small batches (perhaps two weeks worth of work at a time).  From a lean point of view this injects wait time into their process, even though it may just be two weeks, but this wait time is still considered to be waste (muda).  Once again the solution would be for the lean team to identify the dependency ahead of time via look-ahead modelling and negotiate with the agile team.

To summarize, requirements dependencies do in fact occur.  There are strategies to minimize their impact, in particular implementing and better yet deploying the functionality that is being depended upon before the dependent functionality is implemented, but sometimes it just doesn’t work out that way.  So your team will need to be prepared to manage the requirements dependencies that it has on other teams, and similarly be prepared to support other teams with dependencies on them.  In this series of blog postings we’ve seen how Agile<=>Agile and Agile<=>Lean dependencies can be managed, next up is Agile/Lean<=>Traditional.

Managing Requirements Dependencies Between Agile Teams

agile agile

Although we strive to avoid functional dependencies between requirements, the fact is that they occur in practice.  They certainly occur between requirements that are being addressed by a single team and they will even occur between requirements being addressed by different development teams.  This is particularly true between the subteams within a program (a large development team organized into a “team of teams”).

The following diagram depicts a simple situation where there is an agile program organized into five subteams (A thru E).  The way you read the diagram is that the arrows between requirements represent functional dependencies.  In this case the requirement fourth from the top on A’s backlog (A4)  depends on the one that is second from the top (A2) and on B3 (the requirement third from the top on team B’s backlog).  B3 in turn depends on C7, which depends on D3.  D3 depends on E4, which depends on D10, which depends on C12, which depends on D14.  There could very well be dependencies between other requirements, but for this example we’re only worried about the dependencies originating from A4.

Figure 1: Example of functional dependencies between requirements.

Requirements Dependencies Between Teams


Where Do Functional Dependencies Come From?

Functional dependencies occur between requirements for several reasons:

  1. End-user driven.  Functional dependencies occur naturally in the business domain as the result of end user activities.  For example, when a customer opens a bank account there is a functional dependency between the customer and bank account business entities.  Furthermore, functionality such as being able to withdraw from a bank account depends on their being the ability to open a bank account for a customer to begin with.
  2. Requirements decomposition. When a large requirement is decomposed into smaller ones there are dependencies from the original large requirement to the smaller sub-requirements.  An example of this is decomposing an epic, a large story, into several smaller stories.
  3. Technology driven. Some teams will choose to identify requirements for a given platform, subsystem, or architectural layer.  For example, you may identify requirements for systems of engagement, such as applications running on mobile devices, and for systems of record, such as a back-end ERP system.  A requirement for a mobile application may have a dependency on a requirement for a backend system to provide certain behaviors (such as the ability to create, read, update, and delete data).  An example of requirements dependencies driven by architectural layering would be that you may choose to identify user interface (UI) requirements, business rules, and data requirements (via data models perhaps).  A UI requirement depends on the implementation of a business rule which in turn depends on several data-oriented requirements.

Of the three reasons for why functional dependencies exist, the first two are clearly within the purview of a Product Owner (PO).  The third one, technology driven dependencies, can be trickier because many POs will not be familiar with the underlying technologies.  This is one reason why Disciplined Agile Delivery (DAD)’s Architecture Owner (AO) role is so important.  The AO and the PO on a disciplined agile team work very closely together.  AOs will help POs to better understand the implications of the technologies being used as well as to understand potential implications of the technologies (including technology-driven functional dependencies).  These sorts of discussions will occur throughout the lifecycle, although they are particularly important during initial release planning during Inception and during iteration planning and look-ahead planning throughout Construction.


How do You Resolve Functional Dependencies?

Functional dependencies are addressed via three basic strategies:

  1. Reprioritize one or both of the requirements.  When requirement X depends on requirement Y you ideally want to implement Y before, or at least in parallel, to implementing X.  The advantage of reprioritization is that it requires the least amount of work by the development team.  The disadvantage is that when a requirement is reprioritized in this manner the team is no longer working on the highest priority functionality by business value, potentially decreasing the return on investment (ROI) provided by the team.
  2. Mock out the missing functionality until it is available.  Requirement X depends on requirement Y and Y will not be available in time (e.g. X is being worked on right now and Y will be developed in a future iteration).  In this case the development team will implement X to the best of their ability, but will mock out (simulate or stub out) the functionality of Y until it is available.  The advantage of this approach is that it is now possible to demo X so as to get feedback about it.  The disadvantages are that your solution isn’t shippable until the mocked out functionality is implemented (or removed) and that there is the additional work to be done to mock it out.
  3. Rework the requirements to remove the dependency.  If X depends on Y, then one solution might be to refactor X into X1 and X2, where X2 has the functionality dependent on Y but X1 has no dependency.  X1 would be implemented now, and X2 at the same time or after Y is implemented.  For example, a new screen has a dependency on data services being available.  The screen includes five fields, four of which already have data services available but one of which is brand new.  In this case X1 would be to do the work to implement the screen with the four fields and X2 would be the requirement to add the new field once the data was available on the back end. Another solution would be to not add the new data field at all, something you would need to discuss with your stakeholders.

Within an agile environment, functional dependencies are managed by Product Owners.  When the dependencies are between requirements, or more accurately work items, that are being addressed by a single agile team this is fairly straightforward because it’s within the purview of the single product owner.

Now let’s consider how a Product Owner team would manage requirements dependencies within a program, as in the diagram above.  In this case let’s assume that each team has it’s own product owner (PO) whom we’ll refer to as PO-A, PO-B, and so on.  There are three scenarios to consider when managing requirements dependencies:

  1. Within the same sub-team.  An example of this is A4 depends on A2. This is straightforward as a single person, in this case PO-A, is responsible for managing this dependency.
  2. On previously developed functionality.  An example of this is C7 depends on D3.  This should also be straightforward as D3 was implemented in iteration N so it should be available when C7 is implemented during iteration N+1.
  3. On future functionality.  An example of this is B3 depends on C7.  The problem is that we want to implement B3 during iteration N but we currently plan to implement C7 during iteration N+1.  The two product owners, PO-A and PO-B, will need to work together to determine a strategy for resolving the dependency.  They’ll do this via a combination of the strategies described earlier.  They may also need to work closely with the Chief Product Owner to ensure that their reprioritization choices reflect the overall needs of the program.

How would the entire requirements dependency map for A4, as depicted in the diagram above, be resolved?  It depends on what the product owner team decides.  At the present moment the overall requirements dependency chain is to be implemented during iterations N through N+3.  This may in fact be acceptable and the product owners will decide to live with the impact of mocking out functionality until it is available.  Or they may decide to reprioritize the functionality so that it is implemented in a more effective order (perhaps during iteration N+1).  The point is that the product owners will engage in negotiation amongst themselves to determine the best order in which the sub teams will implement the functionality.


How do You Manage Functional Dependencies?

Functional dependencies are managed by the Product Owner, or in the case of a program, the Product Owner team.  The goal is to do just enough work to maintain the dependencies and no more.  When you do not sufficiently maintain the dependencies, perhaps you forget to record that a sub-requirement was created as the result of decomposing a larger parent requirement, then it becomes difficult to ensure that a requirement is properly implemented. When you invest too much effort into maintaining functional dependencies any extra effort beyond the point of sufficiency is a waste.  In short, your dependency map should be just barely good enough (JBGE) for the situation you find yourself in.

There are several options available to you for maintaining a functional dependencies:

  1. Physical dependency map.  With this strategy requirements, such as user stories or features, are captured on paper (typically via index cards or sticky notes) and placed on a whiteboard, corkboard, or table.  On physical boards dependencies can be indicated via physical placement, for example the cards capturing the sub-requirements of a large requirement are placed immediately to the right of the large requirement card.  On a corkboard strings representing requirements could be placed from one card to another and on a whiteboard lines could be drawn to represent the dependencies.  Or IDs could be given to each requirement and any dependencies simply captured on the cards via writing down the appropriate IDs. An example of a physical map include user story maps, see Figure 2 below, that indicate the epic or theme that a story is part of (this is a rudimentary form of dependency mapping).  Another example includes a program plan board, an idea promoted by SAFe, where requirements are mapped to iterations/sprints (columns on the board), to implementation teams (rows on the board), and dependencies indicated via strings or lines.
  2. Simple electronic tool.  Dependencies can be managed using tools such as spreadsheets, word processors, or wikis.
  3. Backlog/work item management tools.  This includes products such as Trello, Atlassian’s JIRA, Rally and VersionOne.  Some of these tools will have native support for managing dependencies where others do not (if the solution is to add a text reference into a freeform notes field then that’s not native support).
  4. Requirements management tools.  This includes products such as Blueprint, Enterprise Architect, or DOORS NG.  Be aware that some of these tools will have native, and more importantly effective, support for agile requirements artifacts such as user stories and acceptance criteria.  Sometimes they will not.


Figure 2. Example of a simple story map.

Story map

Which approach should you take?  Our advice is always to keep it simple and use physical tools if your situation permits.  Having said that, there are advantages and disadvantages to each strategy:

  • Physical dependency maps work well when teams are geographically close (working on the same floor or at least nearby floors in the same building).  When you find yourself with a lot of dependencies to manage, or in a regulatory environment when traceability is mandated, or your team is geographically distributed (even if you just have a few people working from home), you’ll find that you’ll want to consider using electronic tools.
  • Simple electronic tools work well when the team is small to medium sized (say less than 30 people), when the team is geographically distributed in some way, and the dependencies aren’t very complex.
  • Backlog management tools are an effective option if you’re already using them for other reasons (such as managing your work), they natively support dependency mapping, and when physical dependency maps haven’t worked out for you.
  • Requirements management tools are appropriate when you find yourself in complex situations, often at scale.  This includes geographically distributed teams, complex domains, and regulatory situations.


Parting Thoughts

Earlier we said that the diagram represents a “simple” situation.  It is simple in that all five teams are following the same sort of lifecycle, in this case the basic/agile DAD lifecycle.  Furthermore the velocities of the teams are roughly the same, which we did for the convenience of the example.  Usually the team velocities are very different, due to a combination of different team sizes and different levels of productivity.  In a future blog posting we’ll discuss the challenges that arrive when the subteams are following different lifecycles (for example a lean or continuous delivery lifecycle or even a waterfall lifecycle).

Several of the strategies described in the blog posting were first identified in Complex Requirements on an Agile Project (Dr. Dobbs Journal, October 2008).

Disciplined Agile Program Management – The Product Owner Team

Large solution delivery teams, let’s say fifty or more people, are often referred to as programs (programmes in UK English). Such teams are often organized into teams of teams, as depicted in the diagram below.  Each of the sub teams will work on their part of the overall solution and to do so effectively there needs to be coordination between the sub teams.  On large agile teams this coordination often proves to be complex, which is why a leadership team is introduced.  This leadership team coordinates:

  • Requirements. Requirements are managed by the Product Management (also called a Product Owner) team.  This team is made up of the Product Owners from each sub team.  They will meet as needed, typically several times a week. This group is the focus of this blog posting.
  • Technical concerns. The Architecture (or Architecture Owner) team, comprised of the Architecture Owners from each sub team, is responsible for identifying and then governing the architectural strategy for the program.  Activities of this group include negotiating changes to the architecture vision over time, resolving disputes about technical issues between sub teams, and sharing technical learnings across sub teams.  It is common for this team to meet weekly with ad-hoc discussions occurring on an as-needed basis.
  • Management concerns.  Management concerns, such as members of different teams not getting along, transfers of people between teams, and schedule dependencies will be coordinated by the Team Leads from the sub teams.  This team is often called the Product Delivery team or simply the Management team (yuck).  As with the Product Management and Architecture teams this team will meet regularly as appropriate.
  • Itself.  This is the responsibility of the Program Manager. This person may be a Team Lead on one of the sub teams, although more often than not fulfilling this role proves to be a full time job.  The Program Manager will guide the overall program team, ensuring that the three leadership sub teams are working together effectively and that they are meeting to coordinate their own activities as appropriate (and typically on different schedules).

Large Agile Team Organization

Product Management/Ownership Team Organization

The Product Owner in each sub team is a member of the Product Owner team for the program, as depicted in the following diagram.  Individual Product Owners will typically spend 80-90% of their time on activities that are directly related to supporting their sub teams and the rest of the time to requirements management activities at the program level.  The Product Owner team is lead by a Chief Product Owner (CPO).  The CPO may be a PO on a delivery team, this is common on small programs, although for larger programs the responsibility of leading the Product Owner team will prove to be full time work.  In organizations with a strong Product Management culture, the Chief Product Owner may be a senior Product Manager.

Product Owner Team

This team is responsible for requirements management activities within the program.  This includes:

  1. Identifying the initial scope of the program.  The PO team will perform just enough initial requirements modelling, with active stakeholder participation where possible, to identify the initial scope of the program.  This scope is very likely to evolve over time, but for now the goal is to explore the scope sufficiently to get the program headed in the right direction.  See the process goal Explore Initial Scope for more details.
  2. Ongoing requirements elicitation.  A primary job responsibility of anyone in the Product Owner role is to elicit and explore stakeholder requirements.  In the case of a program the entire PO team must coordinate their requirements elicitation efforts.
  3. Assigning requirements to sub teams.  As new requirements are identified the PO team will collaborate to identify the appropriate sub team to perform the work and then assign the work to that team.
  4. Managing requirements dependencies.  There are always dependencies between requirements, and these dependencies should be managed by the appropriate Product Owners.  For example, if a requirement (R1) assigned to sub team A depends on a requirement (R2) assigned to sub team B then ideally R2 should be implemented either before or at the same time as R1.  Otherwise the people implementing R1 will need to mock/stub out the missing functionality until it becomes available.  Read Managing Requirements Dependencies Between Agile Teams  for more details.
  5. Developing a product roadmap.  The PO team is responsible for developing a product roadmap for the program which lays out a high-level business direction for the product. This roadmap should reflect your organization’s overall business roadmap, if you have one.

The Product Owner team will meet as often as they need to.  We’ve seen some PO teams meet on a daily basis for 30 minutes each to manage requirements between sub teams.  We’ve also seen PO teams that meet weekly for two hours to do this work.  The important thing is that they self organize to determine what works best for them.

The Product Owner team may include business analysts (an example of a specialist role in DAD) who supports the POs in working with stakeholders to understand their requirements.  This is particularly important whenever the team is addressing significant domain complexity or whenever stakeholders are geographically dispersed.

Tailoring Considerations

In medium-sized enterprises this Product Owner team approach may be applied to your entire IT department.  In this case the focus of the PO team is that of your entire portfolio of ongoing IT solution delivery efforts and not just a single program of interdependent teams.

In large enterprises the Product Owner team for a program may be part of a larger Product Management team for the entire organization.  More on this in a future blog posting.

If the Requirements Aren’t Changing Your Team is Likely in Trouble

I often run into people who are concerned about changing requirements, or evolving requirements if you like that term better, on software development projects (or product teams as the case may be). This is typically a reflection of their training and background in traditional software development strategies where changing requirements are usually perceived as a problem.

In agile we consider changing requirements to be a good thing and we even embrace the idea that this will happen.  In fact, one philosophy of Disciplined Agile Delivery (DAD) is that changing requirements are a sign of a healthy relationship with your stakeholders. Changing requirements indicate that:

  • Your stakeholders are interested in what you’re working on
  • Your stakeholders are thinking about what you’re producing
  • There are feedback mechanisms in place that enable your stakeholders to change their requirements
  • It is easy (hopefully) for stakeholders to change their requirements as their understanding of their needs evolve

So how do you support changing requirements in practice?  The Disciplined Agile Delivery (DAD) framework includes the “Address Changing Stakeholder Needs” goal which guides you through understanding and selecting the right strategy for prioritizing requirements changes as they occur throughout the lifecycle.  These strategies include, but aren’t limited to Scrum’s Product Backlog Strategy, a more disciplined Work Item List strategy, or a lean Options Pool strategy.  In regulatory situations you may even want to consider a formal change management strategy.  DAD’s process goal-driven approach enables disciplined agile teams to tailor their strategy to meet the situation that they find themselves in, avoiding the challenges seen with methods such as Scrum that prescribe a single strategy (in this case Product Backlogs) that don’t work in all situations.

And of course, to minimize the pain of changing requirements you will need to adopt disciplined development practices such as:

  • Writing high-quality code;
  • Refactoring your work to keep it of high quality;
  • Continuous integration;
  • and even acceptance test-driven development (ATTD)/behavior driven development (BDD).

Exploring Initial Scope on Disciplined Agile Teams

When a disciplined agile project or product team starts one of the process goals which they will likely need to address is Explore Initial Scope.  This is sometimes referred to as initially populating the backlog in the Scrum community, but as you’ll soon see there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.

The process goal diagram for Explore Initial Scope is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

Explore Initial Scope

Let’s consider each process issue:

  • Choose the level of detail.  How much effort should you put into capturing the requirements, if any at all.  A small co-located team may find that capturing user stories on index cards to be sufficient, whereas a team that is geographically distributed across several locations will find that it needs to capture point-form notes about each story using an electronic tool, and a team in a life-critical regulatory environment may need to capture even more detail to the point of doing big requirements up front (BRUF).
  • Explore usage. Although much ado has been made of user stories, and they can be applied quite effectively in a range of situations, the fact is that they’re only one of several options for your team to explore usage of the solution (scenarios, personas, and use cases being other options).
  • Explore the domain. Some teams will choose to do some domain modeling via a data model or class diagram, as well as address other views as appropriate.
  • Explore the process. Many teams will discover that they need to explore the overall workflow, or business process, supported by their solution so as to help them better understand their usage requirements.
  • Explore user interface (UI) needs. Many agile teams will also choose to create user interface prototypes, either low-fidelity UI prototypes using paper or even high-fidelity UI prototypes using a prototyping tool or code, particularly when they face a complex domain.
  • Explore general requirements.  There are several types of functional requirements modeling techniques that can be valuable that don’t fit well into the previous categories.
  • Explore non-functional requirements.  How will non-functional requirements pertaining to availablity, security, performance, and many other issues be addressed?  Teams in straightforward situations may find that capturing them as technical stories may be sufficient.  Teams facing technical complexity, and sometimes even domain complexity, soon discover that they need a more sophisticated strategy.
  • Apply modeling strategy(ies).  How will your team go about working with stakeholders to elicit/discover their perceived needs?  Will they hold informal modeling sessions in an agile modeling space?  Will they hold formal modeling sessions, perhaps following a Joint Application Design (JAD) strategy?  Will they interview people one-on-one?  Combinations thereof?
  • Choose a work item management strategy.  Early in the project you will want to determine how you intend to address changing stakeholder needs throughout the project as this will affect how you address the other process issues in this list.  For example, do you intend to adopt Scrum’s value-driven product backlog strategy, DAD’s risk-value driven work item list, a lean work item pool strategy (as followed by DAD’s lean lifecycle), or even a formal approach?  A team in a strict regulatory environment may be required to have a more formal approach to change management than a team without this restriction.

I wanted to share two important observations about this goal.  First, this goal, along with Identify Initial Technical Strategy, Coordinate Activities, and Move Closer to a Deployable Release seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DA process decision framework provides this guidance.