A sprint backlog consists of all the tasks to be performed. The Sprint Backlog provides additional context for the Daily Scrum by providing the team. With guidance on what they should be accomplishing during the Sprint, beyond completing the work committed at last week’s Daily Scrum. A Product Owner prioritizes items in this list, removing any unnecessary items and adding new ones as necessary. Its relative size is estimated so that it can be compared objectively.
A good product owner will create a sprint backlog with just enough work to fill out the remaining days of your sprint plus perhaps one or two days more (this is roughly equivalent to “padding” your sprint). Padding ensures that if unanticipated work or obstacles arise during the sprint. You and your team will be able to handle them without having to go into overtime. It also helps avoid so-called death marches near the end of a sprint.
Different teams will have different approaches for estimating the size of each task (or story). When I was at ThoughtWorks, we used various combinations of ideal tim. T-shirt sizing , and Fibonacci sequences to quantify our estimates. There are many other techniques out there as well—for example, planning poker [1] —and you may even pick up one or more new strategies from other members of your new team. As you estimate new stories, don’t be too concerned with the exact size. Use it as a tool for planning and prioritization instead.
The definition of done is another useful tool for assessing work. The goal of any project is to deliver working software. Establishing criteria that determine when something is complete. The code across your application may need to be refactored. Focusing on one section at a time (while ensuring all tests pass). It may help expedite this process by avoiding digging up other areas while refactoring. Adhering to the “definition of done” is about accountability. It’s about ensuring everyone on the team knows what it means to deliver working code. In the future, developers (perhaps the next you) can maintain and upgrade it.
Testing is often an afterthought in software development, however, newer methodologies like Agile and DevOps are changing this pattern in business. The main reason for having consistent criteria for testing is to reduce risk. When teams use consistent practices they are less likely to incur unexpected side effects. As changes are made to their applications.
While it’d be great if everyone adhered to the same standard of quality. It’s a common best practice to have a separate environment for continuous integration/delivery processes. Developers can have their own test environments they use on a daily basis. But another one exists for automated tests and quality assurance. In my opinion, this is the proper way of doing things. As you want your CI process free from your developer’s testing databases and settings. That environment should be as similar to production as possible, with the exception of caching tiers not being accessible.
The CI pipeline then runs all tests, builds the container images. And pushes them out to your service registry of choice (can be Azure Container Registry. AWS ECR or self-hosted with Helm especially if you’re on Azure). If everything goes well, it will deploy these services so new versions are available for testing.
Thus sprint backlog is at least in theory always up to date. The sprint backlog is always visible to all developers and other interested parties. For the one or two-week sprint we currently use Trello (see above) and it works pretty well for us. We also use Pivotal Tracker but I don’t like their cards UI as much.
The nice thing about the backlog is that you get a nice list of stories.
