Want to add a new software feature into an old product? Without redesigning or rebuilding it?
You can do that easily… with Scrum.
And, yes, you can do it even if the original product wasn’t developed using Scrum.
In fact, Scrum makes adding to your existing software so much simpler because it focuses on smaller bits of functionality – functionality that can be developed during short-term production sprints.
Here’s how the process works.
Write Your User Stories
In Scrum, pieces of functionality are presented as user stories. Instead of a traditional “business requirements document,” user stories focus on a high-level description of what the feature needs to do and the development team is tasked with determining how to do it.
These user stories are perfect for adding new features to existing software, because they are very lightweight and easy to understand. And they can be easily prioritized so you can decide how much to have the development team “bite off” as you enhance the product.
As for what’s not covered in a user story, 13 Myths About User Stories highlights some of the misconceptions out there. Sometimes, when companies are struggling with Scrum, their difficulties can be traced directly back to mistakes in the user story process.
For a more in-depth look at how your user stories should work, check out our blog post, Writing User Stories – It’s Not as Hard as You Think.
Estimate the Workload
Another difference in Scrum is that managers don’t decide how long a programming task should take, developers do. Once a user story is written, the development team will determine how involved it will be to complete the work and estimate the size of the story. Because those estimates will come from the same people who will be doing the actual work, they tend to be much more accurate than traditional prediction methods.
Accurately estimating in Scrum goes far beyond one individual’s estimate of how many hours or days. It also takes into account the experience of individuals, cohesiveness of the team, and experience in the process. As a project goes on, you’ll find your development team becoming more efficient and able to do more. The Scrum estimating process reflects this.
Read our blog about Agile Software Estimation with Planning Poker to learn how a Scrum team can accurately provide estimates of the work using story points instead of hours or days.
Plan Your Production Sprint
The production sprint planning process plays a key role in Scrum development. While you might want your development team to “get right to it,” cutting corners here can quickly derail your project. First, the Product Owner should have reprioritized your list of outstanding user stories, called the product backlog. This is important, because you always want to be working on what’s most important to you right now. Whether those priorities shift due to new business initiatives, competitive factors, customer feedback, or even from lessons learned during a previous sprint… your Product Owner should always keep the product backlog in the right order.
From there, the development team must decide which user stories to include in the upcoming sprint. Some considerations include:
- The sprint should cover a timeframe of one week to a calendar month.
- No one user story should take up more than 33% of the team’s capacity to work on the project during the sprint. This ensures that unexpected challenges with one user story do not ruin a sprint.
- The sprint should take into account the skill sets available on your development team. You don’t want to overbook some skills and underutilize others. You can line up outside help for your development team if needed, but unless that help is confirmed and ready right now, you shouldn’t incorporate it into the current sprint.
Your production sprint planning should involve not only the development of each feature, but also the time required for testing and fixing bugs.
Complete the Sprint
A sprint should always result in shippable new features. This means features that are fully tested and ready to deploy.
One important thing to note is that it’s more important to complete a sprint than it is to complete a specific user story. All too often, development teams let troublesome user stories hijack their sprints. They don’t consider the sprint completed until everything they committed to is done, and extend the duration of the sprint.
It’s always better to complete your sprint, analyze your successes and your failures (this is called the sprint retrospective in Scrum terms), and incorporate whatever you’ve learned into your next sprint planning session.
Launching into Production
While every sprint should produce a shippable product increment, that doesn’t mean you haveto ship it.
That’s why we say that the product at the end of each sprint should be “shippable” and “production ready” – launching into production is another decision entirely. You may choose to update your production code after every sprint, or wait until enough features have accumulated and then roll them out together. Your choices here rely on a mix of the platform you’re using, your update distribution channels, and the significance and completeness of the features you’ve developed.
In the end, adding new features to existing software is much more manageable when you’re using Scrum. It all starts with writing the right user stories. If you would like some assistance or advice on how to do this with your own software products, we’re ready to help. Please contact us at Ascendle today.
