You have 1 article left to read this month before you need to register a free LeadDev.com account.
Software engineering has become more fluid over the years as Agile and Scrum methodology adoption rates have risen.
The sheer nature of these methodologies mean they lend themselves to supporting and, to some degree, encouraging change in requirements via incremental development. This phenomenon continues the process of refining the requirements and scope of a project as it progresses.
Regardless of project management methodologies and how they handle change in requirements, the initial requirements and backlog have to exist for a project’s commencement. Surprisingly, over 50% of projects miss their mark due to missing requirements not being captured during the initial scoping. The fundamental goal of gathering requirements is to explore, research, and document what success looks like for a given project. These requirements will eventually become a backlog of items representing the tasks needed for project completion without future changes. Such oversight can be problematic and have a disastrous effect on a project’s outcome. With the primary building blocks and assumptions lacking, the possibility of massive changes in order to course-correct will put a strain on deadlines and budgets.
At Headspring, we have developed a strategic approach to backlog grooming that can be adapted to any size or type of project. This article will outline different ways of approaching projects, techniques for gathering requirements, and building a reliable project backlog for project planning, execution, and fulfillment, resulting in a solid foundation for a strong project start.
How to approach a project
Software development projects can fall into several categories: rewrites, system integrations, and building a new greenfield – to name a few. Despite the variation, or how straightforward the objective is, ‘knowing is half the battle’ (a phrase popularized by the G.I. Joe cartoon in the 1980s).
Knowledge surrounding the problem that a stakeholder wants to solve – e.g. existing tools and applications in their ecosystem, business jargon, end-users – and how they all fit into the big picture or domain adds tremendous value. This broad-based knowledge, commonly referred to as ‘domain knowledge’, is applicable and attainable in your current industry or when starting on a client project. Having such knowledge puts you and your team in a better position to grasp the end goal and build a better understanding of the problem while fostering ideas and holding discussions on how best to solve it. In his book, Domain-Driven Design, Eric Evans states that ‘the heart of software is its ability to solve domain-related problems for its user’.
There are several ways to build or improve domain knowledge, many of which are discussed in Eric Evans’s book. The most common is using diagrams as a means of communication, and explanation; the simpler the diagram, the better, as many people respond well to visual cues. Notably, there will always be some form of discovery and learning when a domain model is discussed and drawn out. Leveraging diagrams help establish system boundaries and all the associated entities within that context. Once those boundaries start to form, it will begin to clarify what aspects of the project are in or out of scope.
Techniques for gathering requirements
Similar to starting a project, there are many ways to gather requirements. Starting with domain knowledge puts you on the right path to discovery, asking more questions about the system and the problem that it attempts to address. We can define requirements as the list of things in the application or project domain that we wish to be made valid by delivering the proposed system.
As an example, let’s use a bank’s automated teller machine (ATM) as the proposed system, with a simple goal of allowing users to deposit and withdraw money at any given time.
There are two techniques that we can use to gather and define requirements:
- Modeling on events;
- Modeling on state.
These two go hand-in-hand as ‘modeling on events’ builds on the fact that an event can occur whenever a system entity changes value. Consequently, ‘modeling on state’ looks at the state of the system when an event occurs.
It is important to note that we’ll need to find a corresponding input event for each relevant application domain event. For each applicable state, ensure there is a way for the system to detect it. Finally, for each required action, find a corresponding output event.
Using the ATM and focusing on depositing cash, there is the initial input event of a user inserting their card. With the card insert event, we can start to question the system’s current state. In this case, the state will be the card inserted. The following questions and answers may arise:
- How does the system know that the user inserted a card? -> Card Detection
- How would the system know if a card is valid? -> Read Card
- System read card – does the state of the system change? And is there an output event? -> Valid Card State that will trigger a possible ‘prompt user to enter PIN’ action.
As you can start to see, this process can get very detailed. Using the three questions and answers, we can already document that the system needs to know if a card is valid as a functional requirement.
One thing to keep in mind: depending on the system, multiple input events can occur at once. For example, card insert and camera motion detection can happen within the same time frame, triggering the read card record event respectfully.
Building a project backlog
A project backlog is a complete, high-level list of all the requirements with technical implementation details and time estimates. As a result, using the modeling methods previously mentioned should yield a detailed list of tasks. In the consulting space, a backlog’s task is to help determine the budget for a project. However, estimating these tasks can be difficult and subjective. Most organizations have adopted a sizing model in which they attribute a certain level of effort needed for completion e.g. small, medium, and large. Figuring out what an associated size is equivalent to in hours or days is another feat and is highly dependent on your team’s experience and knowledge.
At Headspring, we’ve observed that creating one application screen involving a CRUD (Create, Read, Update, and Delete) operation is a medium task that, on average, takes three days to complete with appropriate testing included. A small task is usually one day, while a large is five days. A project task with an estimated size between small and large can be assigned to one developer with the reasonable expectation that it can be completed in the estimated time frame.
There are instances where tasks may be too challenging to categorize and estimate due to the sheer nature of the task or lack of expertise. These tasks typically fall within the extra-large-and-above range. As a rule of thumb, we usually try to keep all backlog tasks from going beyond large. A task beyond large suggests that the work needed for completion might be too much for one team member, and can be broken down further.
If the task cannot be broken down or estimated with a degree of confidence, then it’s time to ‘spike it’. To ‘spike’ a task refers to allocating time and accepting the risk to build a proof of concept – ensuring that the body of work is feasible from a technical and schedule perspective. Identifying and performing these spikes early in the project road map can provide confidence for the project’s direction or allow timely course-correction.
Conclusion
As alluded to earlier, software development and project management have evolved and they welcome change. However, the reality is that crucial discoveries always emerge during the design/implementation effort because they were overlooked during the phase of the project where requirements were being gathered. These discoveries are not preventable; nevertheless, they can be reduced by leveraging domain knowledge to understand the system’s interworking, its boundaries, and the problem that the project aims to solve. Correspondingly, we can utilize the modeling techniques to identify the potential events, and state changes to capture the foundational requirements. From there, we can take the requirements and break them down into smaller chunks, if applicable, for appropriate task-sizing and estimation.
Overall, there are many other techniques and thought processes that build upon and support these steps. However, the end goal is to capture as much information as possible regarding the project’s domain in its infancy. Doing so can foster a solid foundation for a substantial project start.
