Agile project management means implementing project management in agile ways. so the next question is what are the differences between agile and conventional project management. On this article, we will discuss five keys different in Agile Project management
- Agile project management means iterative and incremental. Agile project management (APM) works based on the timebox, iterative and incremental. While the conventional process works in sequential
- Agile project management follows the agile manifesto. it means more communication, more focus on people, and more adapt with changes.
- Agile project management adapt to changes, there is no fix scope. The scope always change as long as the people, product, and funding is supported
- Agile project management teams work more dynamic job description rather than role based model. team team like scrum master, product owner, and development team with collective ownership
- Agile project management provides new ways of documentation and tools. The term like user story, sprints events, and provides new way to estimate and to communicate
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
When we discuss about the quality of software, we discuss about how we can deliver less bugs software and correct. This can be done by having a dedicated members that focusing in quality of a software. It can be software tester, quality assurance engineer, or software development engineering test. This article will discuss what we need to do when we have a DevOps project and need to make sure the quality of the outcome.
Failure Reason
Let's we ask ourselves, why the result of our DevOps project / Software Engineering project goes wrong?
Incorrect requirements
Team issues (productivity, miscommunication, mis-coordination)
Untested software (have no time to test)
Radical changes in software (unstable requirements)
Wrong architectural design (wrong technology, wrong design, wrong approaches)
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
What we need to do
So how we can make sure the result of the DevOps project is sufficient. And the failure risk can be reduced by the QA role.
Failure riskQA ActionTask on DevOpsIncorrect requirements Validate the user stories with the customerCheck the actor or roles.
Check the feature
Check the user story Team Issues Doing weekly QA based on the outcome/ deliverable
Learning the demonstration from the developer teamsCheck the deliverable and commitment of the teams in Kanban board
Check the status of the story closed when it is tested Untested SoftwareRetested by doing daily QA with development team
Retested by doing weekly QA with the customerPut bugs and additional tasks to developer team
Creating test plan, test case, and test suite
Creating manual based on test resultRadical Changes in software Creating meeting notes for bugs
Creating notes for changes Put bugs and monitor the progress
Validates the changes, if changes is approved Wrong architectural designDiscussing the information architecture issues with the development teams
Discussing the solution architecture with the development teamsCreating tasks that related with architecture changes.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Daily scrum or daily standup is a way to communicate between team members to understand the heart beat of the project. Daily scrum duration can be 5 minutes to 30 minutes. If you have daily scrum meeting more than 30 minutes, it means you should create another technical discussion informally. The question is, what should i do in daily scrum.
Daily Scrum Agenda
The product owner or development teams open the daily scrum
The development team share updates from the previous day
The development team share the challange or question related with the product
The development team share what they will do in today
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Sprint Review
The development team tests the software
The development teams provide feedbacks based on the specification
The development teams will revise based on the feedback
The development teams will send the result to the customer
The product owner will collaboate with the customer to do demo session
The customer will give a feedback in demo session
The product owner will note the feedback
The development team will accept / postpone the feedback
The product owner will send the updated sprint plan
The customer approves / rejects the sprint plan
Sprint Restropectives
Development team discusses what should improve in the next iteration
development team discusses what went well in the last iteration
the team will commit the next iteration
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
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";
Software engineering is independent. It’s not related with a specific tools. It can be applied in any tools whether Visual Studio, Eclipse, Net Bean, or anything. However, selecting a correct tool and correct method will boost your team productivity.
Microsoft Visual Studio 2010 has a good relationship worth Scrum method. As I mentioned in this post, Scrum has good advantages in integration. However, if you are using XP or Global XP. I created an Indonesian article how to use GXP in Visual Studio ALM. The article is based on our experience in building a project in distributed model.
Adopting Global eXtreme Programming in Visual Studio ALM
If you are still in the middle of nowhere. Here are the rule of thumbs what Agile method that suitable for your project
Scrum is great for middle to enterprise project that has planning driven development.
Global eXtreme Programming is a great stuff for small to medium project when we thinks entirely in code quality and distributed productivity.
How about ICONIX? or RUP?. Well we will discuss it in another post.
@ridife
Adopting scrum is just like adopting any agile method such as extreme Programming or ICONIX. However, Scrum lays out the playing field and rules for the game. the software construction is a game for Scrum. Scrum adoption has two aspects. First, Scrum is rolled out. a mentor teach a team how to play the game of product development using Scrum, the second aspect is do the SCRUM itself including your team and client. A good guide about scrum can be downloaded here
15 pages of Scrum Guide
Schwaber (2007) in his book called Enterprise and Scrum already have 1,2,3 rules to adopt Scrum.
Creating backlog, a simple user story model
Iteration activity as a heart of the Scrum
And working software that increment the functionality
The rules is done by three roles the Product Owner, the team, and the Scrum Master. All management responsibilities in a project are divided between these three roles. The Scrum Master is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so that it fits within an organization's culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices. The Scrum process is simple and mostly focused how team collaborate effectively using daily plan and appropriate tools. You can learn and develop a software with fun using this method. For further knowledge I recommend you to buy book about Scrum
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";