How to Track Software Development Progress?

On this page:

1. Why software development projects are using AGILE methodology?
2. How to divide the scope of project?
3. What are User Stories and Epics?
4. How to monitor the progress daily?
5. What are the best tools to trach development progress?

‍

Measuring progress in an IT project is a top priority issue for both the client and the software development team, as it can play a significant role in the health of the entire project. While the client wants to keep his finger on the pulse for obvious reasons, awareness of progress helps developers stay focused and allows them to prioritize activities. This leads to greater team involvement and the feeling of responsibility for the overall result.

At the same time, this task is difficult due to the specificity of the software development process. It's easy to catch up on tracking the wrong indicators or drawing wrong conclusions, especially when interested people come from industries other than IT.

Monitoring in AGILE framework

Software development organizations have noticed very quickly that short development cycles (sprints) with almost immediate feedback and very strong prioritization of tasks is the best way to make the final product meet customer expectations (which often evolve along with the project).

For this reason, most IT projects are organized in Agile methodologies. Their application also naturally defines how we measure project development - we already have units of work that we can use (User Stories, Epics), we have a time frame (sprint usually takes 1-2 weeks). We can easily define and estimate the scope of work for individual functionalities to then use this data in measurements.

Measuring progress will be more difficult in larger groups or unusual projects. Project management in such cases is complex and challenging. A large part of the responsibility for early detection of possible problems lies with the team.

Planning the software development project

To better understand how to track the development progress, we should start by looking at the initial stages of software development, primarily at the project planning and project division.

The classic approach to organizing work in an agile is to divide the scope of the project into User Stories and Epics, which are groups of related User Stories. Then in a phase of actual software implementation, we are using subsequent cycles consisting of:

• development,
• evaluation,
• feedback,
• planning.

This way we are able to organize the work of developers on a regular basis and monitor progress by reviewing and verifying subsequent sprints. Proper project management is the key here.

User Story is the smallest unit of work in the agile methodology, defining the final goal expressed from the user perspective. It is worth noting that each story has its acceptance criteria, is estimated by developers, has its definitions of done; all these things help us later to evaluate the development of the software project. For example, we estimate the next user story by comparing it to the ones already done, which allows us to accurately predict the time needed to complete it.

While Stories are small units, Epics are a series of related Stories. It is worth noting that it is the epic that will often be an entity that brings real business value, because it usually encloses some functionality that can be added to the system as a whole.

Team "velocity" is a metric that can be defined as the number of work units that a team can deliver in one sprint. This number is usually derived experimentally from the first sprint and then refined after each sprint, as every team and project differs. It’s a good idea for the team velocity to be measured with the resolution of the largest story. Measuring velocity daily is very error-prone, since usually the last 20% of a task takes 80% of the time, and it is not uncommon for the Stories to take longer than one day.

Making correct decisions about the work model at the start of the project is very influential in later stages. Echoes of good or bad calls made at the beginning, whether it concerns the organization of work, the choice of technical solutions, or logic business, can be seen throughout the whole life of the product.

Of course, in agile methodologies, we can quickly catch and correct mistakes in subsequent iterations, but it's still worth keeping in mind that those made in the early stages usually generate the highest costs.

Software Development Phase

Agile methodologies provide us with ways of communication that are also a good means for monitoring the progress of the software development project. Daily standups are particularly important here - in small teams they are responsible for the majority of communication, they are time-efficient and allow insight into the work of the team without unnecessary micromanagement.

In addition to sprint planning, during which we can analyze the current development of the project, estimate the pace of work and capture emerging difficulties, it is worth bearing in mind a number of additional parameters that are characteristic for IT projects and which could have a significant impact on possible delays, even before the first release:

• Timing should be taken into account, e.g. regarding events from the product industry (e.g. meetings with investors, conferences, cyclical events, start/end of a season). These events create natural milestones and it is worth planning the work based on them. After all, the business value is the highest priority in any commercial project.
• Sometimes it happens that the work is not distributed evenly in the team - this can be a sign of insufficient exchange of information, conflicts, or simply lack of knowledge. These types of situations are easier to detect by using tools that limit the number of active tasks that are processed simultaneously (characteristic e.g. in the kanban methodology)
• It is worth checking the current cost of infrastructure and knowing which elements can be expensive at an increased scale (e.g. 3rd party services, cloud hosting)
• Constant changes in requirements create the so-called technical debt. One should be aware of that phenomenon and make sure that the debt is regularly eliminated. Unmanaged technical debt makes it harder to implement changes in the future.

In software development, we often deal with the so-called "90 percent done" syndrome. The best way to deal with it is to prioritize and execute (which requires both product and technical knowledge) - we should regularly control the scope of work and ruthlessly prioritize so that the most important tasks could be tested and verified as soon as possible.

Also, keep in mind that a successful team will regularly provide the client with new features to test. A dedicated staging environment can come in handy here because the client is likely to use new features to introduce the software within the company or the marketplace.

Best tools to track development progress

Less is more. Complicated tools require time to get to know and usually have a lot of functionality that will not be used by a small team anyway. As the project grows, there is a plenty of opinionated software that is well known in the IT world that works just well (Looking at you, Atlassian)

When it comes to the tool for administering an Agile framework for a small to medium-sized team, I would start with Trello, and go no further than JIRA, based on the project size and complexity and personal preferences. It's a main progress checking tool, available to all, from developer to client.

Every team needs additional tools for communication, sharing files and software as well as functionality specific tools (for example for app designs), but these do not contribute much to the progress measurements. However, I believe that transparency on most levels is important when it comes to decision making, so in our company, the client is usually invited to join the developer team in most of the tools we use.

Indicators are known and disliked by programmers, such as the number of lines of code, the number of errors, etc. are not an ideal way to measure the quality of a team's work, especially in a complex project.

In contrast to them, regular conversations with the team, reviews of subsequent sprints, checking the correctness of estimation - these are the closest to the truth measurements of software development progress, allowing the client to keep actual track of the changes. An additional advantage of this approach is entering Agile, encouraging, and allowing regular feedback and participating in the project's life on an ongoing basis.

In the end, remember that according to the Agile Manifesto "Working software is the primary measure of progress" and working for business simply means "one that improves business results". So take a look at the data, remember to communicate with the team but most importantly, ensure that your business grows.

If you’d like to know more about software development for your business, don’t hesitate to get in touch.

‍