Learn more on Rules to Better Scrum.
When initiating a new project in Azure DevOps, selecting the right template is crucial as it sets the groundwork for project management and collaboration. The Scrum template is a recommended choice due to its adherence to widely recognized Scrum terminology and practices. This rule guides you on how to select the Scrum template and elaborates on the benefits of doing so.
Prior to your meeting with the customer you should prepare. Get your Sprint Planning (was Release Plan) email ready, so after the meeting you can adjust and promptly send it.
In Scrum you work only on tasks in a Sprint, and the task must belong to a committed PBI. As such, when you commit code in Azure DevOps (was TFS), you should associate it with the task you are working on rather than the PBI.
In Scrum there is only one report that the team needs to track their progress.
Emails are a natural way for people to give feedback about a product. Unfortunately, they also serve as a poor mechanism for performing work. As work is done, the thread can become untenable by splitting off into multiple different threads and becoming buried among other emails.
That's why when a feedback email is received, it is important to turn it into a Product Backlog Item (PBI) and communicate that back to the sender.
If someone often sends email tasks rather than creating PBIs, kindly suggest they create PBIs directly to save time and keep workflows organized.
In Scrum it's important to flesh out the details of a PBI when it makes sense to do so.
You should estimate your PBIs as soon as you can, but you don't need to break all of your PBIs down into fully-estimated tasks as soon as they're added to the backlog.
However, before starting work on a Sprint, you should always break the PBIs in that Sprint into estimated tasks.
A PBI (Product Backlog Item) is a term commonly used in Agile project management and software development to represent a unit of work. It refers to an item in the Product Backlog, which is a prioritized list of features, enhancements, or fixes to be addressed in a project.
Before a PBI is worked on it should be added to the current Sprint Backlog during Sprint Planning. If your PBI doesn't exist, or is in an email then you need to turn it into a PBI to be prioritized in Sprint Planning.
When an Issue or Product Backlog Item (PBI) is created, it's important that team members review the title and content to ensure it is clear and correct.
Bugs are often hard enough to resolve but when they don't detail how to reproduce the bug, or what the expected behaviour is, it wastes a lot of time and gets frustrating for the developers. Detail in a bug report is key to your teams effectiveness and success. This is not limited to bug reports, for example PBIs can be missing Acceptance Criteria.
Bugs that are introduced and found because of the current work in the Sprint are included in the Sprint and estimated immediately so the burndown remains accurate. All other bugs found independent of the work on the current Sprint are placed on the Product Backlog.
See Do you know when to create bugs? for detailed information on identifying when something is a bug, and when to just fix it.