The changes we’ve made to this process goal include:
We’ve updated Choose Your WoW! to include this release of the Explore Scope process goal. We will soon be updating Introduction to Disciplined Agile Delivery (DAD) 2nd Edition and An Executive’s Guide to Disciplined Agile, so if you have Kindle versions of these books expect updates to come through soon.
Quality requirements, also known as non-functional requirements (NFRs), 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 quality requirement types (the list of concerns). Good sources for quality requirements include your enterprise architects and operations staff, although any stakeholder is a potential source for them.
Figure 1. Architectural views and concerns.
Why Are Quality Requirements Important?
Stakeholders will describe quality 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 quality requirements early in the lifecycle is important because:
Capturing Quality Requirements
Figure 2 depicts the goal diagram for Explore Scope. As you can see, there are several strategies for exploring and potentially capturing quality requirements.
Figure 2. The goal diagram for Explore Scope (click to enlarge).
Let’s explore the three strategies, which can be combined, for capturing quality requirements:
Of course a fourth option would be to not capture quality requirements at all. In theory 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).
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:
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:
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:
There are several strategies the agile team may decide to take:
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:
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.
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.
Figure 2. Lean work management strategy.
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.