Product Backlog with Example in Azure DevOps

Many of the readers, ask me how to create 'the right' product backlog in Azure DevOps. How to make sure that the requirement is correct and sufficient for developing a software. If you already read the previous article here. You will find the basic information about the fields in Azure Boards. If you go further to complete the requirements, you should combine the azure boards fields with the Scrum concept. We will discuss five steps that you need to do to make sure your product backlog Is completed and unambiguity. Let's get started Step 1. Creating features that have values Visit your backlog and make sure you choose Features point of view. Simply stated features are any values that you promised to the customer. You can do that by Choose the backlogs Choose the features Click new work item Good features example QR Code Management, E-Brochure Generator, Student Certificate Management Keep it short and simple an nouns Step 2. Creating short and understandable Product backlog title When it comes to the product backlog you should make sure that you product backlog is aligned with the features. You can do that by clicking on the + sign in the left of your feature so that it aligned After making sure that the product backlog is contributing to your features. Next, you can give your product backlog name. My recommendation is following the format of use case sentences Subject + action + object For example, admin manages the family product, user views the e-brochure, or guest register their account. Step 3. Creating user story in the Description If you click the product backlog, you will have user story descriptions. The user story descriptions should consist of two main information: The user story. For example: as an administrator I want to manage users so that they can access the system The usage scenario description. For example: Admin visit the Users menu System will display the user's pages with user list. User list consists of Username Email Role (Admin, Customer) Status (Active, Not Active) Edit Button Admin click the add button to add the new user OR, click the Edit button to manage existing users System will display the user dialogs Username: cannot be changed for the existing user Email: can be changed Role: check box Status: dropdown list Save, and Cancel button The mockup (optional) and attached in the attachment feature of the product backlog Step 4. Acceptance Criteria is a must Acceptance criteria helps the developer to make sure that the product backlog is tested and fulfill the business rules. You can write your acceptance criteria with one of these rules. \ Test that sentences. For example, Test that every change email will send the old email confirmation and new email acceptance Demonstrate that sentence. For example, demonstrate that the username cannot have same email address. Gherkin syntax: Given, When, Then Given: new user creation When: admin click the add button Then: the system will send you a welcome email Step 5. Writing the Detail This step is optional, but my recommendation is to complete it to make sure the visibility and feasibility of the project Add discussion in azure board every time the requirement changes OR more information needed Put the status and estimate the user story. You can read the detail here Estimating Product Backlog in Azure DevOps ( Ask the development team to create tasks for the product backlog. Task Is the technical activity that Is ordered and belong to the product backlog That's it, thank you! And please put your idea into comments

The Best Way to do Sprint Planning

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 ( 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!

Ordering Product Backlog on A Sprint

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 ( 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

Software Development Best Practices

As a software engineer, i feel overwhelming with the software development process. Although, it's been more than decades to learn about it and plus my doctoral degree is in software engineering. i don't have any confidence that our software will have less bugs, better performance, and stable architecture. This is because several reasons such as: requirements changes lack of better architecture (chaos architecture) untested software So my real question is how we create better software and eliminating that problem. Let's think simple solution about this: Requirements changes --> unavoidable --> we should take care the changes by giving our customer chance to change as long as they pay Lack of better architecture --> can be avoided --> we should create a standard platform in the team and the architect should maintain the document so it should up to date Untested software --> can be avoided --> we can create a standard process to make sure the software is tested and the bugs is eliminated. Requirements Changes the way to improve the requirement process is by Creating a series workshop / meeting session to improve the requirement visibility Managing clear documentation about the requirement and the requirement changes. Tracking the changes about the requirement and the requirement changes. So what tool do you have for these: Azure DevOps Microsoft Planner Microsoft OneNote You can learn further here Manage requirements, Agile methods - Azure DevOps | Microsoft Docs Lack of Better Architecture The way to improve better architecture are: Evaluate the architecture with the architecture best practices Learning the new technology that can fulfill you architectural need Implement standardization of your platform and architecture task So what tool do you have for these: Visual Studio 2022 or later to check the code map, and code analysis Visio or PowerPoint to create and propose your architecture work Azure WIKI to document your architecture You can learn further about the architecting here Visual Studio 2022 architecture feature - Architecture analysis & modeling tools - Visual Studio (Windows) | Microsoft Docs Architecture Center - Azure Architecture Center - Azure Architecture Center | Microsoft Docs Untested Software The way to improve your software quality are: Regular testing. For example, do software testing for each iteration Creating your testing script. For example, you can create manual testing on Azure DevOps or automated testing with Visual Studio Get Feedback from customer. Do feedback session with the client for each iteration. So what tool do you have for these: Visual Studio unit testing and testing feature Azure DevOps testing feature Microsoft Teams for documenting your meeting You can learn further about the testing here Unit test tools - Visual Studio (Windows) | Microsoft Docs What is Azure Test Plans? Manual, exploratory, and automated test tools. - Azure Test Plans | Microsoft Docs

How to keep requirements stable

Everytime, i meet with customer. i feel so happy. This is the first meeting to discuss the requirements. Creating product backlog, creating features, and creating business constraints quites fun. Just imagine, how happy when we get the new project. It means new income, new hope, and new experience. The dream is washed after we in the middle of the projecr. The missing features, the bugs, tha changes from the customer. It drives us crazy when the cost is higher than we expected. The developer team and the product owner conflicts about the requirements. The product owner conflict with the customer about the missing features and business changes.  This article provides you five steps that you can do to limit the changes.  1. Create a mockup before the working solution. You can use mockup to gather feedback from  your customer.  2. Create a regular meeting with customer. weekly meeting with 30 minutes length is fine, 60 minutes is ok. Discuss any progress that you have and any changes that expected by the customer. 3. Create a demonstration session between you and your team. Let's your team demonstrate offered solution and you validate the working product with the mockup 4. Create sprint review with your customer. you demo the solution and get feedback from the customer. Tell them that this solution is based on the feedback in proposed mockup  5. Create documentation workflow to document your meeting, changes, and others artifaces In Azure DevOps you can 1. Use Microsoft Teams to do meeting and demonstration session  2. Use Microsoft Whiteboard to discuss the idea of your product  3. Use Microsoft PowerPoint storyboard to create your low level mockup 4. Use Microsoft Wiki in DevOps to record the meeting notes 5. Use Microsoft Azure Boards to document the user story  6. Use kanban board to understand the changes,      Changes is unavoidable so prepare for the changes happen

The Simplicity in User Manual

User manual is still needed. However, it should as simple as possible. The real question is, what the content of user manual that can be as simple as possible and provide simplicity guide for the user. This article will guide it for you. If you are Scrum or XP user, this agile user manual is for you. This is the improvement of my previous post Creating Agile User Manual ( What you Put in Your Manual Technically not everything on the DevOps work item. You can put the essential information such as Product vision, mission, and success criteria Product version and history Product actor. Who will use the product? Product feature. List of features Product user story Product guide how to use the user story. User story limitation and rules medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

Implement Scrum Product Backlog on Azure Boards

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 ( 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";

Five Things that you do in Visual Studio 2019 to Improve your codes

Building codes is one of the top missions of any software developer in the world. Improving our codes to improve code readability, maintenance, and performance. Today, we will discuss five things that you can do to improve your code's quality by using Visual Studio. Let's get started   // #1 Code analyzers This is a good feature to understand your codes better. This technique uses FX cop to analyze your codes. You will have a recommendation, code-tips, and comments about your codes based on common coding practices #2 Code Cleanup You can run code cleanup to clean and to eliminate useless codes. You can configure the clean up just like a disk cleanup in windows. Less is more. #3 Live share Need a code monkey or support from the expert pals. You can get in touch with them by using Live Share. Live share is a code-sharing feature by using live streaming protocol. You can collaborate with more than five persons to build codes on the same pages. The editing process will be live just like document editing in Office 365. Just give them a link, and you are ready to go #4 Refactoring Refactoring comes with quick action features that allow you to improve the codes through a contextual recommendation. Just hover your codes and choose quick actions and refactoring, you will amaze how refactor process can help you to compose efficient codes. #5 Say no to Copy and Paste Codes Visual Studio has a code clones features to help you identify the repetitive codes. You can run the code clones, and the Visual Studio will help you identify the replicated codes and how to manage it. Pro Tips: Run the code clones, and then refactoring will make you. That's it five tips to manage your codes easily by using Visual Studio 2019, have other tips to improve your codes? Just put in the comment, and I will add it to the list. Enjoy your weekend //

Converting Business Process to User Story

As an Agile developer, you might need to convert your business process to user story. The hard part is to make sure that the user story doesn't eliminate or reduce the clarification of software requirements. On this article, we want to share about five steps to convert your business process to user story. In order to reproduce this tips, we encourage you to register into and understand the DevOps Board. So let's get started // Step 1. Identifying roles / actor This is an easy step; you should convert the swim lane in business process modelling notation / flowchart into a actor or roles. You should identify the relation between one actor with the other. For example, member actor is a registered user who pay the subscription bill. Or admin is a registered user who promoted by another admin. Step 2. Converting the block diagram into action Each block can be converted into a user story action. For example, the order entry can be an action for sales. The credit criteria validation is an action for Management. The action phrase can be used as a title of your backlogs. Step 3. Creating user story phrases Remember the class? You can use this formula to create user story As an (actor) I want to (action) so that (outcome) For example, as a member I want to view unlimited learning videos so that I gain XP (eXperience Point) and knowledge. You can put the title into Boards Step 4. Managing Epic, Features, and Story / Backlog You can start your user story as a baseline of your user requirements. Here is the rule of thumbs: Mission can be an Epic for a software Capability can be features One feature will have one – many user story Our recommendation is start with the user story or features. You can add it into your Azure DevOps. Step 5. Add the Usage Scenario in User Story Description If the business process should be clarified, you can add the detail of business process in the description of the user story. In Azure DevOps you can put business rules and the other process in the description That's it steps to convert the business process to a user story. Happy weekend //

5 Things that you might be forget in Azure DevOps

One DevOps solution that can be used for free and is easy to use is; ah Azure DevOps. Azure DevOps has many features for teams that want to deliver solutions quickly and sustainably. In this article we will discuss five things that you might forget when using Azure DevOps. #1 You Can Import Your Github Repos to Azure DevOps You have a project that has been saved on Github. And you have the desire to continue on Azure DevOps? The good news is that Azure DevOps supports imports from Github. The thing to do is quite simple, just choose import from repository and all your code will be copied. For more details, please refer to the following link  // #2 Converting your private project into public  You have a personal project and want to share it as an open source project. So Azure Devops supports the process of changing projects from private to public and vice versa. Just follow the steps below and you can share the spirit of open source with the world #3 Choosing the Software Method Maybe you are accustomed to using Scrum, but did you know that Azure DevOps has various Agile or formal methods support. You can choose basic, CMMI, agile, and Scrum. When choosing a different process, the terminology, approach, and also Boards will change. Intrigued by the difference please see the following link #4 Managing Requirements Better  Azure DevOps especially Azure Board has a solution to manage software requirements. Azure DevOps can manage work items, sprints, and test cases. Check out the various software at Azure DevOps that can help you here #5 Productive with Queries  When we finish a project. Bugs, work items, and tasks need to be searched and traced quickly. Some use the default search engine, some scroll from one page to another. Did you know if there is a repeat search approach with queries. Check out how to do the following link //

Topics Highlights

About @ridife

This blog will be dedicated to integrate a knowledge between academic and industry need in the Software Engineering, DevOps, Cloud Computing and Microsoft 365 platform. Enjoy this blog and let's get in touch in any social media.


Month List