If you’re always sprinting to the finish, you probably didn’t have a good plan from the start. In this Project Insights article, we’ll cover the planning steps you can take to minimize risk associated with a complex mobile development project. In my first two articles, I covered key aspects to kicking off a project and defining requirements . Now let’s dive into the details for planning out your team’s sprints.
One Size Does Not Fit All
Many product companies follow strict software development processes and roles are clearly defined. A large percentage follow the SCRUM agile methodology. Roles like the Product Owner and SCRUM Master are assigned and team members collaborate based on their responsibilities. Since our clients use varying procedures within their own internal teams, we need to determine the best way for our teams to align. As a mobile agency, POSSIBLE Mobile has to adapt, just like any good agile methodology suggests.
Over time we have discovered that there are key principles from SCRUM that make our projects successful, but also allow us room for flexibility. In the discovery phase, we share our recommended methodology with our clients and then discuss how to integrate that into a process that works best for the team. Our project managers often take on dual responsibilities by performing the SCRUM Master role as well as collaborating with client product owners and assisting with product owner responsibilities. Let’s start from the beginning and discuss how to plan out a sprint release.
During the kickoff phase, priorities are assessed and negotiated for each product release. Since many of our clients have a budget in mind, we work through estimations for all design and development tasks. These estimations can then be used to gain insight into which features can be completed within each development sprint. Since we normally plan out work in two-week sprints, it’s helpful for the team to create a Gantt chart showing what features will be completed in which sprints. This visual creates a roadmap for the release, helping to create alignment within the team. Confluence, from Atlassian, has a great macro called Roadmap Planner that can be used to create a chart.
Typically two to three days before the start of each sprint, the project manager and development lead will meet to pre-plan the next sprint. We evaluate the next set of priorities in the backlog, and consider the team size to plan out the sprint using Atlassian’s workflow tool, JIRA. The sprint can be a mix of design, development, QA, and general tasks that need to be accomplished. Each task contains expectations for the task and typically links to Confluence for more detailed documentation.
In some cases we have clients that want more flexibility and they may only plan one sprint at a time. In this case, it becomes critical for the product owner to keep the backlog of tickets up to date and prioritized. In other situations, we have clients who want to use a KanBan board within JIRA in order to follow a more lean scheduling system for their workflow. This allows for more flexibility and visualization of upcoming backlog items. Workflow steps include limitations to the amount of work that can be in progress at a given time, thus giving the current team a reasonable amount of work to accomplish at a consistent pace.
Sprint Planning meetings allow the team to sync up at the start of a sprint. It’s crucial for all team members to be part of this meeting so expectations are set and the team is aware of any dependencies throughout the sprint. If a designer doesn’t understand their priorities, then development could end up blocked later in the sprint. If QA doesn’t know what features they will be testing, they can’t prepare an adequate test plan.
Many product companies will have a SCRUM Master facilitate the meeting, while the product owner provides clarification on backlog items. At POSSIBLE Mobile, the Project Manager takes on these responsibilities along with assistance from the development lead. In this meeting, features are reviewed in detail and estimations for the work are discussed. If any team members think the estimates are incorrect, there’s time for reevaluation. Some teams even spend time to do poker planning to determine estimates. As soon as the meeting is complete, the sprint is started in JIRA and the team gets to work.
You can stand or you can sit down. You can even take a walk. Don’t tell anyone to take a hike though—that might not go over well. Daily stand-ups are designed to get the team together for a quick meeting to cover these typical stand-up items: What did you do yesterday? What are you doing today? Do you have any blockers? Since JIRA already gives the team a visual of the workflow, I like to focus on blockers, but also ask how team members are trending vs. their estimates.
Let’s start with blockers. As a project manager, it’s my goal to make sure the team isn’t blocked throughout the sprint. If issues come up, the severity of blockers are determined and then dealt with in order. This could range from myself reaching out to a third party with questions on their SDK to getting a lead developer involved to analyze the technical issues a team member is facing. If a question can’t be answered in 30 seconds or less, then the appropriate team members meet to discuss it after the daily stand-up meeting.
Tracking team members’ actuals vs. estimates gives me insight into important questions I need to answer. First, is there a team member that is struggling and could use some help? Or did we estimate incorrectly and need to keep it in mind for future planning? Additionally, is there a performance issue that needs to be addressed? Also, comparing the team’s actual performance against our original estimates gives me the insight I need to determine the project burn. This lets us know if we are trending ahead or behind schedule.
Sprint Release and Demo
The last item I’d like to cover is the sprint release and demo, which is typically done on the last day of the sprint. In a sprint release, we typically review what we’ve accomplished during the sprint as well as demo items that we deem to be feature complete. These may be features that have had only partial QA or may be considered close to ready for final fulfillment. Either way, the benefit of this meeting is to allow the team to showcase what they have accomplished and determine if the team meet their expectations for the sprint. It makes me proud of my team when they demonstrate the designs and features they’ve implemented, particularly when they embrace feedback provided by other team members who find issues that need to be resolved. The more issues we can fix early on, the better off we’ll be when it comes time to regression test and ship.
Whenever possible, it’s helpful to have the product owner on the client side also involved in this meeting. This allows the product owner to see milestone builds during the project to make sure there is alignment. As noted in my previous article, Defining Requirements, the product owner should have already approved the requirements for the features shown in the demo.
Let’s not forget the importance of Sprint Retrospectives as well. This is a time for the team to reflect on their accomplishments and struggles, and also set a priority list for improvements they’d like to make in the future. Since that’s a larger topic, we’ll cover it in a future Project Insights article, so stay tuned.