In this article, we want to discuss creating a project report from Azure DevOps into Microsoft Excel. So, let's get started:
Download the Azure DevOps Office 2019 here Download Visual Studio Tools - Install Free for Windows, Mac, Linux (microsoft.com)
After installing, choose Team Tab and after that click new List
You can add server by put https://dev.azure.com/yourorganization/ . The system will show you to authenticate with Microsoft 365 accounts / Microsoft Account
After successfully authenticating, try to select your project. You can select existing query by clicking query list or choose new
You will tree list as shown below.
After that you can create report by creating chart or insert into Microsoft Project.
After product owner creates product backlog based on the customer voices. The next agenda is to select the product backlog to a sprint. If you are wondering how to create an user story format in product backlog you can see this video. On this video, we will discuss what you need to do in Sprint Planning. There are five steps in sprint planning namely:
Creating a sprint length and release.
Redefining product backlog
Put a backlog into a sprint and reorder it as sprint backlog
Adding the details of Sprint Backlog with Tasks.
The definition of done in a sprint
Creating a sprint length and release
After you have a draft of product backlogs, you can try to create a release.
A release should be discussed with the client. Some of client said a release as a commissioning list of a project. A release is your commitment to deliver values to the customers.
Your customers will approve the timeline for a release. It can be a date namely deadline. For example, your customer said that the system should be released on 19 January 2022. If today is 19 November 2022, you will have two months before the release date. Imagine if your team works for 5 days / week. It means you will have 40 days to catchup.
You can get sprint numbers by dividing a release length with your sprint length. In this example, we have 40 days of works. If your team decide to choose sprint length for 20 days. You will have two sprints.
Sprint length is defined by the development team and product owner.
You might ask why we choose 20 days, why not five days or ten days. Basically, there is no rule of thumbs of the sprint length. However please consider these when you choose the sprint length.
Try to convert the user story points into the duration. You can do that by using your team velocity based on project historical analysis.
Warm boot. Your team has previous experience. You can capture the velocity. For example, they finished 50 user story points for 25 days. It means the velocity is 2 user story points / day. Therefore, if you have the longest product backlog Is 40 points. You can get the sprint length 20 days
Cold boot. Your team has no previous experience. On this case you can ask the development team to convert the points into days.
You can find the sprint length by trying to put related product backlog into a single sprint. For example, you have a related story such as login, registration, and profile. And you can finish in 10 days. It means you can choose 10 days as your sprint length. Try to find the longest related product backlog in your project. And choose that as your sprint length.
The shortest the sprint length the worst in efficiency. For example, you have 5 days of sprint length. It means you will have 4 days of sprint review and sprint retrospective for a month. If you have 10 days of sprint length, you will only have 2 days of sprint review and sprint retrospective. However, if the sprint length is too long, you will face inefficiency when the product backlog changes in term of requirements.
Redefining product backlog
In a sprint planning, you should detail the product backlog. It means you should complete the
Business rules
Stored Data
Usage Scenario
The acceptance criteria
The business values
You can read this post Estimating Product Backlog in Azure DevOps (ridilabs.net) for further information
Reordering Sprint Backlog
After you complete the product backlog, you can put the backlog into a sprint. In Azure Boards, you can navigate to the Sprint menu and do these following:
Reorder the product backlog. You can put the highest priority product backlog in a top
Put the product backlog in a sprint. You can drag and drop your product backlog in a sprint
Adding the details of The Sprint as Task
Task is technical activity that will be done by the development team. You can add the task by visiting the Sprints menu and click the + sign in the left of your backlog. Ask your team to add their personal task such as creating table, setup the middleware server, or even build user interface,
The definition of done (DOD).
DOD is the heart of a sprint closing. For example, you can say the sprint is closed when:
The entire task in a sprint is finished AND,
The backlog is tested and passed the test AND,
The backlog is approved and demonstrated to the customer and they accept it.
You can define your own DOD to close the sprint by doing sprint review and sprint retrospective. In the next post, I will discuss what you will do in Sprint Review and Sprint Retrospective. Put a comment, if you have a question!
One of the most critical activities by the development team in Scrum is ordering the product backlog into sprint backlog. As you know, the product backlog is a user story that developed by the product owner based on the interaction between the product owner and the customer. When product backlog is agreed between customer and the product owner. The product backlog will be stored in a 'place' where the development team can take it and put it on a sprint. A product backlog should be estimated, prioritized, and refined first before putting into a sprint. You can read the estimating method on this post Estimating Product Backlog in Azure DevOps (ridilabs.net). Estimating product backlog gives the information about the size of the product backlog. However, it doesn't give any information about the order of the product backlog. To do that, we need to do several steps such as:
Estimating the product backlog effort size. For example, "as a admin I can set role the employee so that each employee will align with the department and job description". After the discussion, we conclude the 13 points.
Converting the points into a duration. This approach will convert the points into the duration of each point. We name it as velocity. Velocity unit is hours/point. Therefore, the duration will be effort size (points) x velocity (hours/points). The velocity can be obtained from the
Machine learning / prediction of the length. The idea is grabbing a lot of project data and find the similarity between product backlogs and project types. This can be used for anyone who want to get prediction of the duration
Historical analysis. The idea is using the history of the team based on similar project. This can be done of you already have similar project.
Finding the relation of the product backlog. There are two types of relation
Depend on. Profile page depends on the registration page.
Is a dependent of. Registration page is a dependent of profile
After that you can short the product backlog based on dependency for example. You can create matrix of dependency
The higher depend on means you should consider build the product backlog later
The higher dependent of means you should consider build the product sooner
After the ordering you can combine the ordering with the priority. The highest priority should be developed first. If many of the product backlog has many similar priorities try to pick the easiest one.
Now you can split the product backlog into sprint backlog. The idea is to deliver value. So, you can combine two product backlogs into one sprint in order to deliver a value. For example. One sprint length is defined as three product backlogs that have equal in 25 points. The three product backlogs have same value for example: registration, profile, and activation. It has 25 points. If each point equals with 8 hours. It means the sprint length will be 25 points x 8 hours / point. Or 200 hours. You can convert into days when you need to.
Some Research agenda
How to define the velocity in cold start
How to define the sprint length
How to order the product backlog in a sprint
On this article, we will discuss how to implement product backlog on azure boards. It assumed that you already have the feature list. Product backlog is an ordered list for anything that need to build product. Some people said that product backlog is the user story. Yes, it is! But product backlog already has priority and order. This product backlog shall be prepared by the product owner. The product owner can be assigned with the basic license or stakeholder license for the Azure Boards.
Backlog hierarchy (docs.microsoft.com)
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Requirements
Before we go to the product backlog implementation on Azure Boards you should have:
Product owner can access the Azure Boards. The good news is the Stakeholder license in Azure DevOps is free of charge!
Product owner already discussed the priority of the product backlog with the customer
Product owner already estimated the business value of the product backlog
Product owner already have portfolio backlog
What we should do
On this step, we will do several tasks:
Creating the product backlog. It includes the description and acceptance. It will follow the use story format. If you don't know the user story format you can visit this video
Relating the product backlog with the feature
Giving priority, business value, and value area
Let's get started
On this video, I will show you how create, relate, and giving priority of the backlog
What's next
After this step, we can estimate the effort and assigning into the sprint.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";