successful software developmentThese 9 simple steps describe, in outline, the steps I think are important to be successful at software development, regardless of whether you are working in a product or project environment. Some are standard Scrum whereas others are additional activities over and above those defined in the Scrum guide.

1. Identify our Business Goal

Before we do anything, we need to be aware of the current goal of the organisation. Our leaders will have created the business goal during their goal development workshop and it would be especially good if one of them could expound it for us. Without a business goal, we’re just shooting in the dark and have no way of knowing if we are doing the right thing or not. The goal is the ‘why’ of what we’re doing.

2. Create a vision

To achieve the business goal, we need to deliver customer value, our product. Before we start building our product we need to know who the product is for, what need it will fulfil and how it differs from other products. These attributes are all part of the product vision and without high-level guidance on ‘what’ we’re trying to build, our product could end up as a mish-mash of unrelated features. The elevator pitch is a common way of expressing our product vision and is an output from our vision workshop.

3. Plan our next release

Once we’ve agreed what we are trying to build, we can start looking at the outline features and ‘when’ we think they might be delivered. We’ll have a session where we might take part in persona development, user story creating and even do some impact mapping to determine the candidate work for the next few sprints. We might do some spikes to close some of the gaps in our knowledge.

steps of successful software developmentExtreme programmers call this release planning a term also adopted by many Scrum practitioners. SAFe practitioners call it PI Planning and LeSS practitioners call it Initial Product Backlog Refinement. We might also use this time to agree team make-up and working practices. Some Scrum practitioners have a sprint zero where they perform these activities.

There are many other activities and workshops that can be performed during our release planning session but the objective is always the same – to form an ordered backlog for the next period of work. This is our release plan, which tells us roughly what will be done and when over the next 8-12 weeks.

4. Plan the Sprint

Most people understand that software development is best done iteratively and incrementally. In Scrum an iteration is known as a sprint and is most commonly two weeks in length. We’ll start the sprint by doing Sprint Planning, where we’ll take as much work as we think we can comfortably deliver from the release plan and figure out ‘how’ to deliver it by breaking it down into tasks and creating a sprint backlog.

5. Have a daily Scrum

As we work through the sprint, we’ll stop at the same time every day and quickly update the rest of the team as to our progress. Usually in a stand-up meeting where we can update our progress on the sprint burndown chart and task board.

6. Refine our backlog

At some time during the sprint we need to make sure the upcoming work for the next sprint is ready to be planned. i.e. Dependencies and ambiguities resolved, etc. We also need to make sure the outline features in our release plan are detailed enough to fit into the next sprint and are understood well enough to be worked on. We might do some story-splitting or story-mapping to help us with this. We may estimate or re-estimate product backlog items and update the release plan accordingly.

7. Review our Sprint

At the end of the sprint, we will meet with stakeholders in a sprint review to demonstrate what we’ve built and to get feedback from them for the best course of action. They can share in the success we’ve had in the sprint and understand any problems we’ve encountered. Here we’ll have the opportunity to update the release plan and the release burndown chart.

8. Revisit our ways of working

After the review, we can get together as a team in a retrospective to understand how we did things during the sprint. What could we have done better? What should we stop doing? What could we do more of? This is an opportunity to learn how we can improve our learning and performance.

9. Rinse and Repeat

We mentioned earlier this is an iterative process. At the end of each sprint we can see where we are and what, if anything, has changed. Have we run out of work? Then plan another release. Has the business goal changed? If so, go back to the start and identify another goal. Has the product vision changed? Well, you know what to do.

You may already be familiar with these steps, but are unsure of how to perform the specific activities, or on the other hand each of these steps may be completely new to you – either way agil8’s comprehensive suite of fully accredited training will have the right level course for you.

So to develop your skills and knowledge of this area further, take a look at our training portfolio.

View agil8’s Training Portfolio