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
Building custom solution for a customer is challenging. The most challenging part in building custom solution is change requirements. We already know, there is no stable requirements. Every requirement that customer said can be replaced, changed, or added. In requirements engineering, a way to make requirements stable is by doing requirements managements. In this article, we will discuss what requirements management is and how to make sure it can be worked in the requirements that we already developed.
Requirements Management
Requirement management is part of requirement engineering. As we know, requirement management consists of two components. The first one is requirement development as a technique to obtain requirements. The second one is requirement management a way to make sure the requirements can fulfill expectation without sacrificing the development teams. The detail of requirement management can be read here What is Requirements Management | IBM
Although the principle is similar, requirement management can be different in Agile environment. In Agile environment, the requirement management is not structured as in the formal one. The product owner or product manager should handle the requirements management in daily basis. There are several principles that will be adopted in Agile environment.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
There is always 'version zero'. The user story should have version zero. Initial version that will be modified and changes. The team should discuss with the customer for the initial version of user story.
There should be regular meeting with the customer on each iteration. The regular meeting should be happened at least weekly.
There should be a proof of concept (POC). The POC can be viewed by the customer to validate the requirements. Ideally the POC should be sent after a week of regular meeting. The customer can say go or not go based on the POC.
There should be acceptance test that can be tested based the tester or customer to validate the requirements.
There should be unit test for the user story that 'complex' enough to validate and can be done automatically.
There should be a versioning of the user story. This is to make sure changes is documented and logged.
Requirements Changes does not mean it should change!
In agile environment, it is said that the requirements will be changed, and you should manage it. I recommend you to read Agile Requirements Change Management (agilemodeling.com). And here are the quick tips.
When changes happen, do a discussion with the team. What the impact of the changes.
When there is an impact, there will be additional work of solution. On this stage, choose which solution that can be done by the team with two considerations.
Perfection of offered solution.
Least of work solution
The development team chooses which offer that will be given to the customer.
The product owner / product manager will tell the customer about the changes and the 'additional' work and budget.
If the customer agrees, the product owner will add the changes of the user story into the next iteration / sprint.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Agile is a current software process that is believed to be a solution to build a software. On this article, we discuss how to build a software that implemented Agile and DevOps. For the real example, we will use azure DevOps and eXtreme Programming (XP). Let us get started:
#1 Creating a DevOps project
After the project is agreed and the contract is raised, the team can start to create a DevOps project. They should do:
Choose the process template (in this case we choose Agile). You can learn step by step here Create a project - Azure DevOps | Microsoft Docs
Invite your development teams, product owner, and others stakeholder.
Set the iteration path. You can learn step by step here Define iteration paths and configure team iterations - Azure Boards | Microsoft Docs
Preparing the development environment. You can deploy the development infrastructure in Azure and connecting to your DevOps. You can connect by using service hooks.
You use Azure Service Manager if you connect with Azure Subscription that SAME
with your Active Directory.
You use Azure Classic if you connect with Azure Subscription that different with your Azure Active Directory.
You can use Terraform If you want to publish your solution to Amazon AWS.
Creating initial project with Visual Studio and push it into GitHub or Azure DevOps.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
#2 Composing the user stories.
This step is a casual XP based requirement engineering technique.
Creating features,
Defining the actor or persona
Creating user stories, https://youtu.be/2Qj3x1RnqHA
Creating iteration plan with user stories deliverables
Discussing the features, user story, and iteration plan with the customer
#3 Designing the Solution.
You start this step by creating a mockup for your design. You can start with.
Creating information architecture (IA). You can create the IA with Mindmap software such as MindManager or XMind.
Create low fidelity prototype. You cab create with your pencil & paper or user wireframe tool like PowerPoint or Balsamiq.
Discussing the low fidelity and IA with the customer
Creating high fidelity with Visual Studio or Visual Studio Codes.
Uploading and presenting the High-fidelity prototype to customer
#4 Developing the Solution.
This step can be the longest step in the project. This is because the solution is developed through one or more of iteration. Of course, this step is executed iteratively.
Since we are using XP, the development team (tester) should create a test suite, test plan, and test case. You can see the video here https://youtu.be/0GKPguP4qLU
The developer should create unit test in Visual Studio.
The developer should create the codes to fulfill the user story.
The developer will commit and check-in daily to the repositories.
The CI/CD process will deliver the nightly build.
The iteration review will be happened in two stages.
Internal play testing – with the development team.
Customer play testing – with the costumer
Revising and getting feedback from the customer or from the defect.
Iteration retrospective with the development team and others. It discusses how to improve the next iteration of the development such as:
How we communicate with the customer
What we need to change in the next iteration
How the development progress so far
Deploying the solution for the iteration.
Continuing to the other iteration
#5 Implementing the solution.
After the entire iteration is finished, it is a good time to implement and to finish the solution.
Confirming the customer that the solution is appropriate to be deployed.
After the confirmation, the development team can create documentation such as:
User manual
Developer manual (optional)
Doing several workshops to socialize the system.
Gathering the feedback for continuous improvement.
Ready for the next improvement and for the next project.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
So our business analyst ready to kick off a project. the real question is what should we do in release planning session. A session where we start the project for the first time. On this article, we will discuss the main activity in release planning. the activities follow the eXtreme Programming method. Let's get started
Writing Story
The business analyst should write user story as comprehensive as possible. the business analyst will create
set features. i.e. Registration Feature
user story i.e. as a member i can register through social media account so that i dont need to fill basic information
acceptance criteria i.e. member should have at least first name, last name, organization, and email
Estimate the Story
The business analyst should elaborate with the customer to do several things
Validating the user story with the customer
Detailing the user story and acceptance criteria with the customer
Estimating the story point with the development team
Creating the release plan
The business analyst will do several activity to make the plan is solid
Discussing the story depedency with the developer
Discussing the story priority with the customer
Creating iteration plan that contain user story
Stabilzing the release plan
The business analyst should understand that the story will be changed. Therefore, the business analyst should stabilising the plan by doing several activities
iteration review with the customer / weekly progress with the customer
documenting feedback based on the review
reviewieng the changes into updated story
discussing the detail of the story with the task with software development team
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Programming is a challenging task. You need to focus, to solve a problem, and to create a solution for problem. There are so many ways to do programming. In Agile environment, programming can be done through three ways. Solo programming, Pair Programming, and Mob Programming. This article will discuss when you choose one compare to the others.
Solo (all in one)
This is just like a song from Katty Perry featuring Clean Bandit. Solo! Solo means you do by yourself. You did plan, do, codes, and test activities. The solo great when
Project is simple and less complexity.
Less external dependencies and stakeholders.
Limited user experience
Benefits of solo programming are:
Faster in development
Codes are understandable.
Easy to manage.
Challenge in solo programming is:
Limited design principles applied during the development process.
Exhausted and bored
Undocumented codes
You can learn more here The Personal Software Process (PSP) (cmu.edu)
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Pair (~2 developers in same role)
Pair is a couple way to do programming activity. Pair programming is great when.
Pair is available with different skills and knowledge.
Pair is great when face-to-face communication.
Pair is great when we have same role in a team.
Benefits of pair programming are:
Well-design product two head is better than one.
Transfer knowledge happens.
Shared ownership of the codes. The pair knows the codes.
Challenge in pair programming is:
Slow down the productivity.
Hard to implement in distributed environments (e.g., different time zones)
Suitability of pair person.
You can learn more about pair programming here On Pair Programming (martinfowler.com)
Mob (> 2 members in different role)
Mob is more than two peoples work together. Mob is great when.
Having members with different skillset
Having a good workspace to work together.
Having a jell team with good communication model.
Benefits of mob programming
Project understandability is the highest among the team members.
Validation and verification happen between members.
Near real time feedback model to shape the well-designed project
Challenge in mob programming
Specific infrastructure is needed.
The communication between members should be fluid between team members.
Limited productivity when the others work while the others only see the process.
You can learn mob programming here Mob Programming Basics – Mob Programming
So which one you prefer as your programming style? Put a comment please.
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";
Why your Customer does not read your user manual?
If you still wondering why the user manual is never read by the customer, or why your customer still asks to you although you already have the user manual. this article is for you. On this article, we discuss a new way to create user manual by using SnagIt. Snagit is more than Screenshot application. it helps you to create screenshot for your manual, create a step by step video, or event simple vlogging to introduce yourself. Today, we have a mission to create modern user manual with Snagit.
Snagit can help you to create more appealing user manual in order to increase the user awareness. Of course, building fancy user manual is not solve the entire problem since we also need to create agile user manual. This article is second article from our first article "Creating Agile Manual". If you don't know what Agile user manual is and why you should care, you can visit the previous post. So, what is the characteristic of Agile user manual is?
Providing the user multimodal communication. i.e. the user can read the manual, view the visual illustration, or see the video to finish the task.
Providing interaction. i.e. the user can comment and ask you about the specific topic regarding the user guide
Available online. The modern user manual should be accessed through online through web.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
How Snagit can help?
Snagit can help you to create better look and feel in your agile user manual by providing some of key features such as:
Providing you multimodal recording
Snagit 2021 can help you to record
Onscreen video with better compression and quality ratio. This is the most feature that I love so much. Comparing with the other screen recording software, Snagit is clearly the winner of the compression vs quality. It provides you low size video without compromising the quality.
Screenshot. You can record screenshot just like the casual print screen. However, Snagit provides you a better way to screenshot anything that cannot see in the screen, such as your scrolled content. As a web developer of Single Page Application, Snagit 2021 will help me to screenshot the whole web page.
Creating gif video. If you want to record the video with less than 30 seconds, you can export the video to 'tiny size' animation.
Providing you a getting started template to create your manual
In Snagit 2021, Snagit Editor provides you a ready to use template to create the user manual. You can choose from the basic 2 steps, 3 steps, till 5 steps. What a good in Snagit 2021 template is:
Built in usability in mind. The template guides you to create Agile user manual in usability and avoid 'overload information'
Supporting real world scenario such as
User manual
Request for changes (before and after)
User interface explanation (for poster and quick guide)
Enriching visual cue in your User Manual
In the past, I should create a manual shape and put a number on it. Snagit 2021 provides you more than a shape. For example, my favorite one is a Step. Step provides you a visual cue for your manual. It makes your user manual is better. You just need click your mouse and the label will be automatically assigned.
Reusing and Managing the Information
If you are creating a user manual for more than one customer, you face situation when you need to do screenshot similar steps (i.e. login to Azure portal). With Snagit 2021, you can manage your reusable library and tag it with useful keyword. You can change the view from Capture to Library and you can reuse your existing slide. The library give you a good classification for your previous capture such as images, video, or animation gif. And of course you can search with your tags (i.e. Azure)
Sharing to the others App
After using the Snagit, you can share the content to make you more productive such as.
Sharing the content to your google drive so you can insert it into a blogger-based site.
Sharing the content to SharePoint or Slack to get a feedback from your teammate
Sharing the content to Camtasia so you can edit the video
Snagit support major application that might need to use it
That's it! Let me know if you need detail tutorial about how to use Snagit in Bahasa Indonesia!
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
The challenges with our user manual
User manual is something that is sometimes forgotten. Even though we know that a person's understanding of one system is different from another. We sometime neglect the benefit of user manual for sharing knowledge between the development team with the end-users. The challenges of the current user manual is:
Video user manual – visually rich!
Slow on update. Making a video for user manual is great, but the effort to create a video for something that 'constantly' changes is huge. (-)
There is a lot of effort to design, create, render, and share the video. (-)
Hard to find the specific information if you do not split your video or indexing it (-)
Document user manual – completed and easy to maintain!
the user does not read your document. They only receive as part of your invoice. (-)
Some users are too busy to read the user manual. They tend to learn the application through learning by doing (-)
The demonstration is though through document, you should do a lot screenshot for your document (-)
In app user manual - interactive and integrated with your app!
The user manual is not easy to update since it should follow the build rules in the application (-)
The user manual is separated in several menus, sometimes it hard to maintain (-)
In app user manual needs extra effort in development side. Context based, wizard, tool tips adds the task for development team (-)
The Agile User Manual
Agile user manual is an initiative to make user manual as a live document with several principles
Easier to deploy and to update
Providing quick problem-solution
Rich in content you can put video, document, or even tweet from your company update
The idea of agile user manual is providing the user live document with better usability and access.
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
How to create Agile User Manual
This is an example how the agile user manual is created
Choosing the 'live' platform that can be shared to your users. For example, we are using Microsoft Sway as our 'live' platform https://sway.office.com/
Choosing the easy to use video creation platform for your screensharing. For example, we are using Techsmith Snagit 2021
The steps that we can do is
Create a Sway document with your company account (not the personal one)
Share the sway document with the others development teams
Create a layout. Each layout is a slide for certain functionality
Create a short video with Snagit. You can create less than three-minute videos for delivering the functionality of your application bases on a layout
Put the short video into the sway document
Share the Sway document to your customer
You can see the tutorial in the next post. Enjoy!
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
When developing a software, you might think what is the better way to acquire the requirements. If you learn software engineering you might be remember about software requirements or requirement engineering. It is a long journey to learn about requirement engineering. You should read a lot documentation, create requierement template for your client, filling the document and discuss within the client. If you have done already you might be agreed that sometimes the 30 pages requirement page won’t satisfies the client if they change they mind. You put a lot of effort to create the req’ document but in the end is useless when client changes his mind. In this article, I will share you about what you need to know to create better requirement based on my thought on ALM (Application Lifecycle Management) minimalist. Please note, that ALM minimalist is not a formal method like waterfall, but is an Agile technique that simplify the ALM. If you akready use the Visual Studio Online, you might be familiar with Features, Stories, and Tasks on the Work Tab as shown in figure below. In the picture we have features, stories, and tasks. We will describe it in this post each element of that to make your requirement simpler and adapt to change. Starting with Features. If you ever read a good book about FDD (Feature Driven Development), you might be remember about features. Feature is the unit of the “things that it wants by the customer’. In the ALM Minimalist, feature is simple statement that explicit the client need. On the Visual Studio Online, you can add features by clicking the work tab and click the new button. Here are several sample of feature The simple patterns of Feature is Features = Action + Object Feature should also provides additional information such as Who owns the feature. it means who will responsible with that feature The prioriy of the feature (1 for high priority, 3 for less priority) The iteration when the feature will be develop. In Visual Studio Online, you will get a lot filed to fill by clicking the feature. However, ALM minimalist encourages you to keep it simple by avoiding fields Exploring Features into Stories So you have features, you can break down into stories. For example, if we have a feature called “Managing The Payment of a Course” you might have several stories such as Paying the course using wire transfer Paying the course using credit card Paying the course using invoice from company As you see, story explains the feature more detail based on several constraint and condition based on customer needs. On Agile book such as eXtreme Programming Explained or others, you will find that the user story has a pattern like below User Story = as a (actor) I want to (action) so that (benefit) for example: as a member I want to pay the course by credit card so that I can join the online course right away In Visual Studio Online, you can do that easily by clicking the stories menu. However, if you feel too complex when writing the formula, you can follow the simple statement such as “Paying the course using credit card”. You can make the story unambigous by adding several information such as Work assigned to (Story Owner). it covers who will do the story Risk (1 high - 3 low) Story Point. Story point is number of estimation that will be done through planning game session Description. It shows the detail of the story. It is just like usage scenario of the story that described using words Storyboard. It shows the flow of the story and the user interface. it uses Powerpoint to create the storyboard Iteration. The iteration shows when the story will be worked by the story owner, Story is a part of feature. Therefore, you can see the story below of a feature on Visual Studio. In the Figure, it is shown that the story name is ‘simple statement’ about the story, and the desriptions uses the “user story format”. You can add the additional information such as data field and detail information on a storyboard Doing the user story action on a task Task is the lowest unit of the work. Task is assigned to an agile member. Task represents the detail of user story. For example if I have story “see the student list”, I might be have 2 tasks such as showing the student list that already paid the course, showing the student that not already paid. If I have 20 story point, each task should be have not more than 20 point. Task is not only about the activity that contains development activity but also others activity such as design, requirements, deployment, and etc. Fortunately, in Visual Studio Online you can create task and assign them with several field such as figure below Conclusion ALM Minimalist is an agile technique that has a purpose to simplify the requirements engineering activity. it proposes the three main components which are Feature, Story, and Tasks (FST). The FST can be adopted easily on Visual Studio Online using Agile MSF template. Good Book to Read
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";