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.
A Product Backlog is a great way to see the fairly small broken up Product Backlog Items (PBIs) that make up your team's "to do" list, but it can be a bit too zoomed in and makes it easy to stray from the Product Goal.
To get a better zoomed out view, you should have a product roadmap.
Initializing the Project - See how to get the work items into Azure DevOps via Excel:
If a work item is related to another Work Item or is a duplicate request, create a link between them on Azure DevOps.
Unfortunately the Azure DevOps team did not have time to build the feature to create a SharePoint site, after the project is created. Next version, we hope.
The goal is always to complete Product Backlog Items (PBIs) for the Sprint Review.
Often PBIs grow or change and it does not make sense to deliver what was originally proposed in the Acceptance Criteria.
All good Scrum teams have a backlog. The backlog is built by taking a conversation and recording it as one or more Product Backlog Items (PBIs) (e.g. Azure DevOps) or Issues (e.g. GitHub, JIRA).
You should create PBIs during or straight after the conversation, rather than using emails that may never be entered into the backlog.
Figure: Get typing during a conversation to make the meeting tangible
The Product Owner is responsible for owning the Product Backlog. See the video on "Do you know how to be a good Product Owner?"
Although these requirements come from the Product Owner, it is often the developers who will record these PBIs.
A Minimum Viable Product (MVP) is the core of your application that you should be aiming to build before you spend time on nice-to-haves, bells-and-whistles, and stretch-goals.
With automatically sent backlog emails (Azure DevOps or GitHub), there is a risk of people deleting them without reading the content – it doesn't happen with manual emails that have unique subjects and a real person as the sender.
Key updates on projects may include Done Videos, critical text additions, or specification documents. Typically, links to these deliverables would be added to the PBI that they relate to and the relevant people would be mentioned.