Building software is not easy as it gets. The technical complexity and non-technical complexity are combined. On this article, we will discuss the process and the steps to build working software in 30 days. Now let's discuss about the steps. There are 5 steps that you can follow when building working software. Before we start, let's define what is working software
Working software is software that not only have good quality (less bugs) but also acceptable by the users.
The next question is; what is the ten steps to build working software? To answer this, you need to understand the Scrum first. Scrum is software method to build software in Agile way. If you are new to Scrum my recommendation is to read this short tutorial What is Scrum? - Azure DevOps | Microsoft Learn. Let's discuss the steps.
Step 1. Defining the Epic.
Let's say your customers want to build Smart Gate for their office. The epic will be.
Helping our guest and employee access the office without touch.
Of course, on a project, it might have more than one epic. However, I recommend you stick on one epic on a single release.
Figure 1. Courtesy of Rebel Scrum
Step 2. Defining The Features
Features are anything that can be done by the system. The point of view of the features are the system NOT the user. Features are capability of the system. For example, on a Smart Gate you will have features:
- System is recognizing the employee
- System is authenticating the guest
- System is calculating the parking bill for the guest.
The capability of the system comes from the discussion between customer and the Scrum Team. Therefore, you should put one or two sessions of discussion with the client. I recommend you to draw the Business Process Modelling Notation to put the entire features into a single big picture.
Step 3. Defining The Product Backlog
The product backlog is a commissioning list that describe the commitment of the customer and the Scrum team to develop the working software. The product backlogs are anything that users will do with our system. For example, on a smart gate the product backlog will be:
- As an employee I want to access the office gate touchless so that employee can access without hassle
- As an invited guest I want to get free access by scanning the invitation letter so that invited guest can access the office free.
- As an uninvited guest I want to get access so that I can visit the office
The earlier format namely user story format. You can write the product backlog for the entire project. However, please aware that the product backlog might be changed later. Product backlog will have.
- The title
- The usage scenario / description
- The acceptance of the backlog
You can read the detail about the product backlog here Estimating Product Backlog in Azure DevOps (ridilabs.net)
Step 4. Defining the Sprint Goal
The Sprint goal is a commitment of the scrum team to deliver working software in a timebox. Basically, sprint goal consists of
- Sprint length. The time box that you proposed to the customer. For example, you commit to deliver working software in 30 days / sprint
- Sprint iteration. How many sprints on a release. For example, you have 30 backlog and you put 6 iteration or equal with 30-day x 6 sprint = 180 days for a release
- Spring Backlog. The product backlog that selected by the customer into the sprint. For example, you have 30 product backlogs, and you choose which one that will be stored in sprint 1, sprint 2, and so on.
Step 5. The Details of the Backlog
The evil is in the detail. Therefore, you should detail the product backlog by using several mechanisms such as:
- Detailing the user experience by creating the mockup
- Detailing the database by creating the mockup
- Detailing the business process and business rule by discussing with the customer through mockup
Only run the sprint session after you already have commitment about the business process and the user experience.
On the next article, we will discuss how to facilitates the customer expectation and knowledge. Stay tune!