In our last post we examined what app development looks like for your designers. In this post we’ll examine the same timeframe with your development team in mind.
With your provisional roadmap in place and a solid sense of the key features that will make up your release, there is plenty for the development team to start working on well ahead of having access to detailed requirements and final designs. Here we’ll discuss the three basic phases of your product build:
• Sprint 0
• Development Sprints
• Release Readiness Sprint
A lot of work needs to be done before the first line of code is written, but luckily you’ll have plenty of time. Your design team will need a few weeks to define and design the first key features of the app.
In this phase, you’ll need to select the foundational technology that the app will be built with. Often this decision is a balance between the best tech for the job and the tech that the team is most comfortable maintaining and supporting in the long-haul. In this step you should make decisions about what architecture and technology stack will be used for the project.
Next, you’ll be selecting and configuring the tools that your development team will use throughout the project. Things such as source control, ticketing, and continuous integration must be specified (and in some cases approved by IT) before you’re ready to move forward.
Communication is also an important and often overlooked part of app development. You’ll need to determine how members of the product team will share what they're working on so that you can easily monitor their progress on assigned tasks and assess any impacts to your overarching budget or timeline. It’s also important for the design team, development team, and other stakeholders in the project to agree on the ubiquitous language they will use to describe the various problems they aim to solve. It’s critical to make sure that communication between development, project management, and business is tight enough so that any issues are detected early and often and discussed by the entire team.
Finally, you’ll need to take a first pass at your app architecture to help the team break the work into manageable chunks that support both accurate estimation and facilitate teams larger than one or two developers working on the project at any one time.
At the end of Sprint 0, your team should feel confident not only about what they’re building, but where they’re starting and what tools and communication strategies they’ll be expected to use throughout the project.
Typical Sprint 0 Outcomes Include:
• Selection of foundational technology
• Identification of your tooling
• Definition of your SDLC (Software Development Lifecycle) and project processes
• High level application architecture
There are a few keys to success that you should aim to achieve as you plan this phase of your product delivery:
Regardless of the complications associated with estimating software development, it’s reasonable and recommended that your team provide you with a target they’ll be working towards in each sprint. This sprint “commitment” will focus the team throughout the duration of the sprint and help set and manage internal expectations around what will be accomplished. When you’re dividing up work for sprints, it’s critical to ensure that development tasks or tickets are divided into as close to three-hour chunks of work as possible. This serves a few purposes: First - the developer can’t get too lost in a large-scale implementation detail. Second - it helps ensure code review tasks are efficient and less prone to missing errors.
Once a target has been set for the sprint, the development team will work within the SDLC process agreed to in Sprint 0 to deliver the code within focus for this sprint. At Tonic, we have a hard and fast rule that every piece of work/ticket goes through at least three phases within this step including:
• Development A developer writes code to deliver the work as described in the ticket
• Code-review A 2nd developer checks their work, who is equally accountable as the original developer
• QA A QA team member verifies that they have met all relevant acceptance criteria for this work.
We believe that putting three sets of eyes on each piece of work keeps us honest and identifies issues early and often, both of which are critical for success.
Finally, the sprint wraps up with a demo which should include the entire project team and any non-technical or business stakeholders that are involved in the project. This demo should be simple enough to understand for people without development skills and should clearly show the progress towards the desired end-project. In this demo (and accompanying notes), we’ll determine our progress (or lack thereof) against our sprint commitment, detail anything that remains undone, and update our status against project risks, budget, and timeline.
The last step in any given development sprint is the planning of the next sprint commitment given the realities of where the current sprint left off.
Typical Development Sprint Outcomes Include:
• Sprint plan or “commitment”
• Code is written/reviewed/QA’ed
• Sprint demo & notes
• Plan the next sprint
Release Readiness Sprint
The release readiness sprint looks different for every project you work on and will be heavily dependent on what you accomplish during Sprint 0 since the stage will define what a release candidate means. This way you can identify the proper time to code freeze on feature development and start focusing on cleaning up and polishing the final product.
You could theoretically spend forever fixing bugs and polishing your app. It’s crucial for the development team to prioritize and estimate any bugs in the backlog and work within those parameters that should be determined in the scope. At this stage of development, you need to be focused on the end result of the product. Feature enhancements can be left for a later update (i.e. you don’t want to introduce more potential bugs to your app).
When your dev team reaches the end of their release readiness sprint, they should have final development source code as well as any design and copy assets that may be needed in order to submit to the app store.
Are you interested in learning more about Tonic’s approach to development and execution? Drop us a line at firstname.lastname@example.org.