At Tyrannosaurus Tech, we follow an agile project management style that involves a tailored approach driven by your strategic business goals and your users’ specific needs and preferences. We discussed the tools, touchpoints, and tactics to accomplish this agile approach in our previous blog post. Next, we’ll take a closer look at your project life cycle’s iterations stage, where our team demonstrates features as they are developed. We’ll discuss what goes into a given sprint/iteration and the essential tools and methods we use to execute our process efficiently.
Build. Test. Repeat.
Our agile methodology encourages frequent communication between all parties and calls for a regular review of deliverables and progress throughout a project. A project is typically divided into one-week intervals, called an iteration or sprint. Inside each iteration, our team picks up work they can complete within that interval and demonstrates their work to you and other stakeholders.
This approach differs from the traditional waterfall method, where you may only see the reviewable product or deliverable when it’s fully complete. The main issue with this approach is that it leaves your precious feedback out of the development process, resulting in minimal visibility into the project’s progress and misaligned expectations. We prefer to manage your product in a space that encourages transparent communication so you can deliver feedback early and often.
A Deep Dive into Iterations (a.k.a. Sprints)
At a high level, a sprint or iteration usually contains the following meetings:
- Backlog Grooming
- Sprint Planning
- Daily Standup
- Retrospective
- Demo
Grooming: Traditionally, grooming happens at the end of the previous sprint and sets up the subsequent planning meeting for success. Grooming allows for our team to review upcoming work and accomplish the following:
- Ensure tasks are small enough to be completed in one sprint.
- Identify blockers and dependencies for a given task.
- Prioritize the tasks relative to the broader backlog.
Each task should be small enough to be completed within that sprint and represent an individual user story (in contrast to something too broad in definition for the developer or designer to finish in one sprint).
Sprint Planning: We kick off a sprint with planning meetings. Our team will review what work is available and prioritized. The project manager addresses each team member, reviewing available tasks and assigning them for the sprint. The team member also estimates the level of effort to complete that task (more on this below).
Retrospective: After two weeks of work, our internal project team meets for a retrospective. The retrospective allows the project manager to recognize team members for quality work and identify areas of improvement for upcoming sprints.
Demo: Finally, our team will demo their work to you. The demo is your opportunity to provide feedback both in free form (and in a documented form within 48 hours), so the team can incorporate any changes into the upcoming sprint.
Estimating by Complexity vs. Time
Traditional software teams give estimates in a time format of days, weeks, or months. Alternatively, our agile team will measure the sprint by complexity when they prepare to take on new work in a sprint and need to estimate the level of effort.
To calculate this estimate, we use a story point system. Story points are units of measure that we use to estimate the overall effort required to implement a particular task. Our approach looks like this:
- Text change
- Simple task, bug
- Simple yet defined feature
- As complex as is acceptable in a single sprint, touches multiple parts of the codebase
- Takes more than one sprint, very complex, needs to be broken down further
Over time, this system helps our team accurately predict what they can complete in any given sprint. For example, we may find that we can handle roughly two three-point stories and one one-point story per resource (i.e., developer) per sprint.
We prefer to use the point system because the point-based estimates reflect the level of uncertainty relative to the sprint’s growing complexity. In other words, estimating by time doesn’t help you measure the certainty of the estimate, whereas measuring by complexity does. For this reason, we recommend using story point estimates for the best accuracy.
Working Together Through Iterations
In agile development, our goal is to gather user and client feedback early so we can iterate often. The last thing we want is to invest in a solution that doesn’t align with your expectations or your users’ needs. We also recognize that when your organization plans your annual budget, you want to have a sense of how much something will cost and how long it will take. We believe the best way to bridge this gap is through transparency. It’s our job to help you understand the trade-offs involved in proposed scope changes and help you stay in control of those decisions and implications. Now that you have a better grasp of our collaborative process, let’s get started chasing mammoth opportunities together.