Agile Project Management

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 

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

Quality Assurance of DevOps Project

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

what should i do in daily sprint?

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

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

Global eXtreme Programming, ALM, and Visual Studio 2010

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

Scrum as a Simple Software Method

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

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