5 Examples of First Sprint Deliverables for Enterprise Applications
From the moment we begin writing code, we aim to deliver code. It may take only a short amount of a single developer’s time to scaffold a project. Determining data models may be brief as well. Describing the application with user stories is no different. In a first Sprint, we deliver, and then every Sprint thereafter, we deliver again.
EXAMPLE 1: A brand new green-field project
Likely, this Sprint will include agreeing to data models that will be core to the application. On top of that, it will likely cover how the data models will relate to each other and a completed iteration that can be built on.
When the data models are completed, it is possible to start developing a database and API that allows data to be accessed by an application. A starter API can be delivered by the end of the Sprint.
When the data models are completed, it is possible to start mocking data that the team can use to design a prototype. It is also possible to deliver a starter application that displays the browser's data or on a mobile device.
EXAMPLE 2: An overhaul of an existing application
When an application is being overhauled, data models probably exist. In the first Sprint of the overhaul, we might decide to alter the data models to achieve new results that are desired. It might be that the data models must stay the same to maintain legacy access to the data. In both cases, the first Sprint can deliver certainty around what data models will be built in the new application.
An API and database may already exist, and that could mean there is no need for any server deliverables in the first Sprint of the overhaul. It might be that there will be necessary integrations with the existing infrastructure. In the first Sprint, it is possible to deliver successful requests and receive correct responses that the new application will be using.
Overhauling an application often means developing new views and interactions that the user will see and experience. There are potentially brand and look-and-feel considerations that need to continue in the new application. In the first Sprint, it is possible to port existing components to the new application architecture.
EXAMPLE 3: Process to process communication
When making multiple processes communicate with one another, there are either minimal user interface deliverables or none at all. This is possibly the same for data modeling work, either none or only a minimal layer.
Deliverables achievable in the first Sprint can be “perfect case” demonstrations of the processes communicating. That means, given data that is input without any errors, then data can be delivered from one process to another successfully. Future Sprints can address cases that have errors or complex interactions.
Another deliverable may be creating the technical blueprints to describe how the processes are going to communicate with one another. This is often a deliverable that stems from two processes not being built in a way that they can communicate in a standards-based way. An example: when data is available from processes with APIs that follow RESTful standards then there are often straight-forward methods of making them communicate. When data is being pulled from a process that has a RESTful API into a directory on an internally hosted corporate server, then more upfront work is done to ensure that this communication can occur reliably.
EXAMPLE 4: Business process improvement
Deliverables on business process improvements achieved with software tend towards favoring substance over style. They need to work well, and looking good is not a part of the necessary outcomes.
Deliverables here can be User Stories that communicate in clear terms where the improvements need to be made to reduce wasteful activities or increase productivity. It is core to the success of the project that the results are measurable.
Deliverables can be a translation of requirements into a functional prototype that demonstrates the process an end-user will be implementing.
EXAMPLE 5: Skunkworks project inside the enterprise
Deliverables in this type of application need to be not only functional but also need to look and feel good to use.
During the first Sprint, deliverables for Skunkworks projects can be functional components that demonstrate the new controls available to application users. Functional components may be included in a scaffolded application or in isolation on standalone pages.
Data modeling matters in skunkworks applications as much as in green-field projects, and a deliverable looks similar. An iteration of data models can probably be completed in a first Sprint to communicate the fundamental inputs and outputs that will be in the application.
BONUS: A First Sprint Team
A team can grow as an application does; accordingly, there are generally fewer people working on a project at the beginning than there are at the end. It is possible that the team will stay the same size for the entire project, and more often, there are fluctuations to accommodate the various phases of development.
All enterprise applications begin with a scrum master, a product owner, and a developer team. The practical needs for all persons to be full-time are often non-existent, and because of that, the scrum master and product owner are often part-time to begin. The developer team is only made of those people who are developing the necessary deliverables to get started. In early development Sprints, it can be better to have fewer members on the team to focus on listening to user’s needs and being sure of them rather than creating discussion among developers about technical considerations that can be missing the mark on what a user will use.
A Sprint Team might include a total of a single full-time person’s time spread across three individual people for early-stage projects being created as a result of the new application. The largest representation will be from the Product Owner and the developer, while the Scrum Master is involved strictly only when necessary. When a project is further along, and now this Sprint is continuing, it is possible to have a full-time product owner, a handful of developers, and a half-time scrum master. It is possible that the scrum master not be full-time on the project, even on some of the largest applications.
