In software development, you’ve probably heard the oh-so common yet bone-chilling phrase “it’s just a small tweak, shouldn’t be too hard, right?” Anyone who is involved in the day-to-day activities of software development knows that this “small tweak” requires prioritization in an extensive product backlog, grooming, planning, developing, testing and deploying; but yes, it shouldn’t be too hard. If you’ve found yourself in the above situation, we’ve got you covered on everything scrum-related and how to get that small tweak out the door in a minimal amount of time.
Scrum drastically reduces time to market and provides what is fundamentally a very simple way of managing software development more effectively. It is one of the most popular frameworks for executing agile; the reason being, scrum has a unique essence because of the commitment to short iterations of work, typically lasting one to two weeks in duration. Scrum provides a lightweight process framework that adopts iterative and incremental practices, allowing both large and small scale organizations to deliver working applications more frequently.
Projects and products evolve over time via a series of iterations called sprints, ultimately leading to a deliverable product element at the end of each sprint. Realistically it takes 3-4 sprints for the team to get into a rhythm, to apply the improvements and get used to the process. Before you start sprinting, it’s imperative to define requirements and properly groom stories which supports the “sizing,” or rank by importance, of each user story. You may be asking yourself what scale should you use for your sizing system? The easiest ranking method is to use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987…
Unless you are developing the next spaceship flying to Mars, I’d start with the range of 1-13. Anything larger than a 13 should be broken down into multiple stories. Now that the limits have been set, sizing the remainder of the backlog shouldn’t be too difficult.
The following steps bring structure to each Scrum sprint.
1. Create A Plan of Attack
In sprint planning meetings, the team reviews last sprint’s velocity and the resource allocation for the upcoming sprint (i.e. remove time for planned vacations). The team members determine the number of user stories that they can commit to and pulls in groomed user stories from the sprint backlog. For the stories planned in the upcoming sprint, the team defines the sub-tasks (with hour estimates) required to complete the user story.
2. Sprint, Don't Walk
Sprints range from 1 to 2 weeks during which the team sprints to achieve the goal they committed to during the planning stages. Sprint duration and the stories planned in the sprint are fixed and should not be adjusted after the sprint is started. The team should do everything that is needed to complete the planed stories in the sprint (this could mean a BA is helping with QA, or a PM is helping with documentation, etc.)
Done Means DONE
It’s imperative to make sure you complete one feature/story at a time before moving on to the next. Reaching the end of the sprint with 85% of each story complete allows you to deliver nothing to the client. YOUR KEY TAKEWAY: It’s better to have 100% of something than 85% of everything.
3. Stand Up, Don't Sit Down
Hold daily stand-ups, 15-minute mini-meeting check-ins for the development team to synchronize on what they worked on the prior day, will work on today, and identify any blockers prohibiting them from moving on to the next.
4. Let's Demo!
Plan meetings where the team displays what they've built in that sprint. Having the opportunity to show off new work at the sprint demo is exciting and the constant, incremental feedback the team gets from stakeholders at each demo creates a powerful way to develop products and enhancements.
5. Start, Stop, Continue
A sprint retrospective reviews what did and didn't go well with opportunities and actions to make the next sprint better. In short, what should we start, stop and continue doing to improve the next sprint, with each item leading directly to change.
In closing, development using an agile methodology preserves a product’s market significance and guarantees a team’s hard work never goes unreleased. Decreased time to market, increased customer satisfaction and stronger team morale are some of the benefits your projects may start experiencing by adopting scrum methodology.