In the many years that we have been helping our clients, some common questions have been asked about what it’s like to work with an agile software development partner using a Scrum framework. In this article, we explore some of the most important of these questions.
The proper use of an agile methodology to develop your software product provides you with these two main benefits:
It is not a requirement to be agile experts to work with an agile software development partner. A quality software partner will educate the client on the agile process as the project proceeds. Many of our clients are not familiar with agile when they hire us. Ascendle is great at teaching the agile principles and folding our clients in easily so they understand the process. A good software development partner will put their clients at ease by teaching the principles throughout the entire process.
It is not required for you to use agile, but an understanding of the general agile principles as well as your primary responsibilities are required. As mentioned above, this learning of the agile principles can occur during the project execution.
A basic understanding of the agile principles is important so that you, as the client, know how you fit into the software development process. Working with the product owner to update and prioritize the product backlog defines what work is to be completed and the order it is to be completed in. Attending the sprint reviews and providing feedback on completed work gives the development team the immediate direction necessary to refine their work to match your exact expectations. These two actions are the primary responsibilities of the client and are critical to the success of the project.
Step 1: Identify the Features
When a project is started, we typically start with a “Strategy Phase.” The purpose of this phase is to make sure we fully understand the client’s goals, product, priorities, and business objectives. During this phase, brainstorming meetings are held to build a “dream list” of features. Nothing is held back at this stage. These brainstorming sessions are very important, and it’s best to capture as much information as possible. After these features are captured, we prioritize them into 3 main groups: “Must-Haves,” “Nice to Haves,” and “Someday Maybes”.
Step 2: Estimate the Features
Next we estimate the relative size of each feature, called a user story. After the estimating is complete, you can see how much work it’s going to take to complete all of the user stories in each group. At that point, the stories can be re-prioritized to get the size of the “Must-Haves” group, or the MVP phase of the project, to a size that fits the project schedule and budget. At the end of the Strategy Phase, we will create an estimate of a project completion date based on these size values and a “typical” production speed.
Step 3: Establish Velocity
After the development phase of the project is ongoing, we can establish the true production speed of the development teams, or velocity, typically after 3 sprints. This is the time where we can sharpen our estimate of a completion date range and create an optimistic and a pessimistic completion date for the project. We can then start the discussion of how to adjust the scope of the project to suit the scheduling and budget needs if necessary.
I love getting this question because this shows the true power of Scrum. A huge benefit of this framework is the ability to use the history of the team’s previous work, the velocity, to accurately predict how much time it takes to complete future work. Applying the team’s velocity to the remaining user stories in the product backlog can predict the completion date of the project. Of course, the more history there is to pull from, the better the prediction will be. Once a completion date is calculated, you have the power to change that date to suit your needs by adjusting the scope of the project. Following this process, it’s almost impossible for a project to go off track!
As we all know, things happen and business priorities change. Perhaps you find out that you need some new functionality added to the project to make an important sale. For this case, new features could be added to the product backlog while the development team is working on a sprint. At sprint review, the priority of these new stories should be positioned where they belong in the sorted list of stories in the product backlog. It should also be determined if these new stories should be part of the current release. If so, it can be shown how adding those stories to the release affects the estimated completion time of that release. Is this later date acceptable? If not, it can then be determined what stories should be removed from the release to make the release date when you want. Typically, these would be the lowest priority stories in that release.
This is exactly the reason we review the product backlog on a regular basis with our clients. You are involved in determining the scope of the release and the estimated completion date. There are no surprises at the end of the project.
This question brings up another great example of the many benefits of using agile software development. At the end of every 2-week sprint, you will have a sprint review meeting with your development team. During this meeting, they will show you the work that they completed during the sprint. All work that is shown is at a “potentially shippable” state. This means that it has gone through all stages of quality assurance and is ready to be deployed to production.
During the sprint review, you have an opportunity to see the software application come to life. Piece by piece, you are seeing how it is evolving. At any time, if there are some changes you want to make, you can discuss those at the sprint review and shape the design of the product. You also have the ability at this time to completely change course if you see the development team is going in the wrong direction, or business objectives/priorities have shifted. The power of this approach is that you are seeing the product every 2 weeks and always have the reassurance that it is following your vision.
There are many things that you can do to help make the project go as smoothly as possible.
If the agile principles are followed correctly this situation should be avoided, but things can happen. Some of the development team could get sick, or work is delayed due to outside dependencies. For whatever the reason, a reputable agile software development partner should have a policy in place if they fail to deliver. At Ascendle, we are committed to producing fully-tested, working software, reviewed by you, every two weeks. At the end of any 2-week sprint, if you feel we didn’t deliver business value, we will invite you not to pay for that sprint. That is our guarantee.