In Agile oriented projects, we usually organise teamwork in Sprints for two weeks, to a maximum of one month.
As you already know, Sprint Backlog is essential to keeping the developers’ pace of work during Sprints. But there are several other practices to support your team members. What might those be? Let’s find out!
1. Limit Work Items In-Progress
A good starting point would be the continuous inventory of backlog.
You should set limits on how many ‘in progress’ items you can have in the sprint backlog. There are few methods to limit work in progress. I prefer to use MoSCoW, which I found to be convenient for prioritising requirements. Appropriate priorities give us the big picture and the possibility to ‘play Sprint Backlog by ear.’
To sum up, we distinguish the most from the least important requirements. This action is vital as the application must have this functionality. Next, we carry out the essential instances first and try to keep to the limit of tasks started. In this case, we should not start anything new until the current tasks have finished.
2. Assign Work
Assign the in-progress work item to the team member responsible for performing the work. The reason for this is functional, as most management tools allow you to assign work to only a single user. So, if we need to assign work to additional users, we will add a work item for each user and distinguish them by title, description, and, most importantly, tag.
To better plan your work, make sure to read more about Sprint Planning.
3. Update the State of Work Items
When we create the work item, the default state is the first state in the workflow – most often ‘NEW.’ As work progresses, you should update the items’ status to reflect current development, i.e., if they are in progress or completed.
4. Update Remaining Work
During the sprint, we update the estimation of the remaining work to reflect the time required to complete the task. This value can even increase after work begins. As we perform a task, we may require additional time.
For example, after working 4 hours on an 8-hour estimated task, the team member may realise they need 16 additional hours, as we require a different solution than initially thought. Updating Remaining Work during daily meetings helps us stay informed of the progress.
5. Capture Comments in a Management Tool
As work progresses, it is natural that we discuss task details which are why teams should also refer to communication tools. But it is good practice to capture the essence of those comments in the discussion section of the task in various project management tools. Why? Most of them touch upon the critical issue of executed work. So, appropriate comments under the tasks clarify doubts and facilitate the work of testers.
Likewise, the text content of the tool’s comments module will enter the associated ‘history’ log. So, if we’re after breadcrumbs of old requirements, we only need to filter through the history’s items.
6. Add Details for Upcoming Sprint Tasks
Before your team can start work on any item, they’ll need more details. Our job will be to point out your requirements by showing the purpose of the developer’s work before adding attachments with examples, drafts, or conceptions. In the chart below, you can see the example of analyses. This figure concerns the user story made by a management team member to accelerate the developer’s work.
The contents are as follows: As a user, I would like to register a complaint to specify my requests for the service to be brought into conformity with the contract.
7. Keep an Eye on Your Team’s Software Development Methods
There are few core engineering practices which we use in every project. These include the following:
Continuous integration
This represents the frequent, regular incorporation of ongoing code changes into the central repository and verification of each executed change.
Pair programming
This consists of the joint work of two programmers, one of whom is the main coder. At the same time, the other coder observes, reports corrections, proposes other solutions, and maintains code coverage with automatic tests.
Code refactoring
This involves the changing of existing code into a more readable and maintainable variant. As I have already written, it is worth pre-emptively considering the maintenance of the application.
8. Keep Sprint Backlog In-Order
What does it mean? I use styling rules in my Sprint Backlog to maintain order and follow all changes during sprints. Using the Azure DevOps tool, I apply five crucial rules to highlight work items for:
- Severity bugs
- High priority items
- High effort items
- Items unchanged in the last five days
- Items containing specific tags: backend, frontend, or mobile
Additionally, by the end of the sprint, I update the status of fully completed items. All work items that remain dormant or had not been attempted by the developer are moved to a later or different iteration or returned to the backlog.
9. Monitor the Pace of Work
During sprints, we monitor the sprint pace of work thanks to the burndown report, which determines if your team is on track.
In Azure DevOps, for instance, this report derives analytical data and monitors the pace of work based on estimations or an exact count of work items. The sprint burndown chart helps monitor progress by indicating remaining work for a given sprint.
10. Maintain Regular Customer Contact
One of our most important tasks is regular contact with our customers. During such meetings, we present completed work, detail any requirements while also confirming the libraries and finished third-party solutions used.
Final Considerations
To sum up, our work during the sprint mainly concerns developers’ preparation to concentrate on the development. We also keep an eye on and monitor the pace of work to facilitate the task, deliver the planned scope, as well as support developers when they need it in tasks that do not require programming knowledge.
I hope this list will bring about better organisation to your team, and I wish you all the best in organising your project’s sprints!
