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 (ridilabs.net)
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
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
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
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
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 (ridilabs.net)
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";
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";
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
//
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 devops.azure.com 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
//
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
//