fbpx
Hero Illustration
0 Comments
Agile, Software Development, Working Software

Working Software to Measure Project Progress

Since agile principles have been pushing us to produce working software in a shorter iteration, the backlog items are geared more toward the story completion, rather than toward the architecture layers slicing. This may sound like a simple concept, but it fixes the major issues that often occur in traditional waterfall projects. In waterfall projects, how the tasks are broken down and prioritised makes the working software demonstrated much later. Therefore, we often get a false sense of task completion.

A story describes how the user will interact with the system and what is expected. Story completion involves implementing some sets of functionalities which allow the user to interact with the system and produce the expected result. In earlier sprints, we may have not completed the stories with all the required functionalities, but they are still stories that allow the users to interact with the system under the development and show how they address the users’ needs. In agile terminology, it is called ‘business-facing’ test type. Business-facing tests address the users’ concerns rather than the developers’ concerns. User story completion is a great way to demonstrate that the software is working.

The method used to distribute the development tasks determines whether the working software can be used as a primary measure of the project progress. When the development tasks are distributed and prioritized based on the architecture layers (front end, middle layer, back end, etc.) or known as “horizontal slicing”, the working software may not be easily demonstrated in a short iteration. With horizontal slicing, we can still use mock-up, driver, or stub to test the architecture layers earlier. However, this requires the use of test automation and may not be a valid business-facing test. At the end of the sprint, not only the implementation of the stories committed for that sprint is demonstrated, but we mainly demonstrate that the software is working.

We will still need to ensure that the stories implemented in the previous sprints work well in the current sprint. Some of the stories considered ‘done’ in the previous sprints, could be broken now due to the changes in the source code during the development activities in a sprint.

In the traditional projects using waterfall, manual performing full regression may not be so much of an issue due to the longer durations between software releases. However, with the shorter iteration in the agile project, it may not be feasible to do proper regression tests for two-week sprints with manual testing. We would need to rely more on test automation to achieve this. Since scrum methodology allows a sprint duration of up to a month, we have the option of a longer sprint duration than the typical two-week sprints. This amount of time allows more proper regression testing to be done in each sprint, rather than having the testing cycle done outside of the sprint.

Working software is so much more than just a set of functional requirements being implemented. We also need to include non-functional requirements, such as performance, security, reliability, scalability, maintainability, and usability. While agile is not a traditional waterfall methodology, it will still hold that if we fail to include the non-functional backlog items incrementally, as appropriate in the earlier sprints; it will lead to large-scale refactoring later.

In today’s market, when the window of opportunity is open, it is important to maximize it and do the right thing to achieve the desired outcome. Missing the window of opportunity will result in a greater Cost of Delay. For instance, the original iPhone, released in 2007, didn’t have a copy-and-paste feature. Those functionalities were added 2 years later, on iPhone OS 3.0. As of 2020, iPhone still stays as one of the top 5 positions in smartphone sales worldwide. By adopting incremental working product deliveries in short iteration to show the progress, the Cost of Delay can be minimized. A good MVP (Minimum Viable Product) may not have all the nice-to-have features. However, with the set of important working functionalities implemented in a product and delivered at the right time, it could be a winner.

Contact us to learn more!

Please complete the brief information below and we will follow up shortly.

    ** All fields are required
    Leave a comment