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.
Let’s consider each process issue:
- 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).
- View types. What types of models should the team create? 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). 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. Similarly they may choose to do some domain modeling via a data model or class diagram, as well as address other views as appropriate.
- Modeling strategy. 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?
- 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.
- 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.
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 DAD process decision framework provides this guidance.