Requirements (Epic, Feature, User Story), Task Size and Estimation in Agile and Scrum

 

 

Introduction

Product Planning

Sprint planning

Conclusion


Introduction

Having the right size for the Backlog items and the tasks is crucial for smooth and successful sprint delivery. Agile and Scrum is a User Story or Product Backlog Item (PBI) driven approach and this approach is overcoming some of the major notches in delivering the product that customer is seeking to have.

 

Portfolio_Backlog

Usually there is a huge gap between customers and the people who are responsible for building the product, but still in order to create a successful product, both sides should communicate with each other in most efficient way. This implicates that communication and understanding the requirements is crucial in delivering the product that customer has actually envisioned.

 

This post will describe briefly some of the practices that I have captured, while visiting some of my customers and also some of the practices that I recommend to consider when defining the requirements, within usage of VSTS.

 

 

TipYou can find more information about DevOps in the following post: DevOps: The Three Stage Conversation – People, Process, Products which describes the basic principles of DevOps. This post will be especially helpful to those for whom DevOps is still a new concept. If you prefer a deeper view on this topic, have a look at the following guide: quick guide about Basic Principles of DevOps, which presents an overview of DevOps process and practices, describing “the big picture”, while still maintaining the high level of detail.

 

Product Planning

The first step that you would want to do is to discuss the high-level plan with your customer, which will be your first input. Here is where you will need to understand first well the high-level plan and later on, more detailed requirements in order to being able to dis-aggregate the plan to some smaller items.

 

Remember, if you are building the product for a customer, that this division is done based on the information that you currently have at hand. Of course, if you are building the project for yourself, many of the requirements will be clear or at least you will think that they are clear in this phase.

 

However, VSTS allows users to plan structure the project based on their needs, but there are still some key points that you would want to consider while planning the delivery of the product. As the user story should be Independent, Estimable, Small and Testable (among other criteria), it should be considered as item that should be delivered in days. Having this thought in mind, you can start building your product Backlog around this idea.

 

If the user story, which is in VSTS captured as PBI (Product Backlog Item), is delivered in days, then we should map the user story to a feature which will be usually delivered in weeks. A small remark: when I am referring to “being delivered”, I am referring to delivering a fully working piece of product or service. This means that this item has been tested and it meets all the requirements for deployment to productions. Furthermore, it means that there is no dependencies and that this item can be used a completely independent piece of product with its full functionality.

 

Having this in mind and if you have already faced with the structure of VSTS Backlog, you may already understand the following structure.

 

Epic –> Months

Feature —> Weeks

User Story/PBI —>Days

 

Requirements size- Epic-Feature-PBI-User Story-Task

 

 

What this means is that we usually use Epics as items that will be fully delivered in months, Features as items that can be delivered in weeks and User Stories or PBIs as items that can be delivered in days.

 

VSTS backlog-Epic-Feature-PBI-Bug

 

More InfoIf you want to know more about maintaining the backlog in a proper way, you can visit the following post: Key Tips For Maintaining Good Product Backlog in Agile and Scrum. The post describes a way to efficiently organize the backlog items allowing you to understand the requirements better, and providing you with higher level of detail of what is actually expected from the work or delivery perspective.

 

Bear in mind, that if your project goes further than presented above, you will be able also add additional levels to your product backlog. Please see picture below for more insights about the levels and structure that can be adjusted in VSTS to achieve the desired product management. In total, you can have seven levels, starting from the very top and going to the task level.

 

five-levels-portfolio-backlogs

 

Sprint planning

Once when you will reach to the point where you will start to work on the user story, you will want to consider cutting the user story even into smaller tasks. There are many reasons, why you would want to slice the user story or PBI to a Task, and one of the reasons is that this particular user story will not be developed just by one person or developer or even pair of developers. In many cases one PBI or User Story is developed by two or more developers or people who specialize in certain part of User Story. In this case slicing the User Story to a Task will be the fastest and most efficient way to deliver it.

 

In VSTS, using Agile approach we usually use tasks as items that can be delivered within hours and is shared between different developers.

 

Task —> Hours

 

 

Tip The post User stories in Agile world focuses on an important unit of Agile software development process, which is User Story. The post also describes some basic rules and recommendations you have to follow before adding the descriptions of PBI.

 

More InfoIn some of the previous posts you can find high-level descriptions of Agile principles and the usage of some Agile tools and Agile methodology.

 

Planning Poker

There are many estimation techniques that different teams use in order to estimate the effort to complete work items and Planning Poker is one of the widely used ones.

 

In the Planning Poker session, the team will have usually a short discussion about requirements, in order to make sure that everyone understands them very well and after that each team member will estimate the effort that could be spent in delivering that work item. Crucial point here is that team needs to understand well all the work items, in order to being able to estimated them. If the team doesn’t understand the requirements well, they cannot then make a good estimation.

 

The team will not use time duration for this estimation, but they will use story points, which can use scale like Fibonacci sequence, t-shirt sizes as XS, S, M, L, XL, XXL or even a custom-made scale.
Planning poker with story points and t-shirt size

 

The Planning Poker usually involves all the team or teams, as each team or member will see the estimation from their perspective.

 

For the teams using VSTS, there is also a Planning Poker extension, which will bring great benefits for the estimation part. As the extension is a part of VSTS, it will automatically transfer the agreed story points directly on to the work items.

 

Tip Read detailed explanation about all types of Scrum and Agile meetings (Sprint Planning, Stand-up, Grooming, Sprint Review, Retrospective Meeting) in my past post Types of meetings in Scrum and Agile

 

Backlog Estimation and sizing techniques

 

Recommended backlog estimation techniques are different for different levels of backlog. Picture below is showing that it’s recommended to estimate items on higher level, which have biger scope and they belong to portfolio backlog items with t-shirt sizes, such as XL, L, M, etc.

 

The items on the high level are many times associated for example with the cost range (e.g. small project will cost between $10k and $25k). In this way we can think about effort in more abstract way.

 

When we move to the next level on product backlog it’s more convenient to estimate items in storypoints as they will be the best option for estimation when we are considering team members with different skills. For example, two programmers of differing productivity will be able to agree with storypoints estimation about the amount of work, the complexity and the possible risks.

 

If we go to the Sprint level, we need to consider team’s capacity which is measured in hours and for this reason, it’s pretty convenient to estimate tasks in the hours.

Recommended Estimation for Backlog Theme Epic Feature User Story and Tasks

 

 

Tip If you are in a situation when you need to integrate two backlogs, read the step-by-step post about Two Backlog Integration in which I am providing a detailed description of the integration between Trello and VSTS using Zapier.

 

More InfoThere are many VSTS extensions designed to make the work process easier. One of them is the Delivery Plans extension providing a better cross-team visibility. Read more about it in my post Delivery Plans Extension for VSTS and learn how to manage more than one team in a much easier way.

 

Conclusion

Every project should of course have tailored and well customized Backlog, which will fully capture all the requirements and will be able to show the progress of the project. But as explained in this post, there are some basic guidelines that you would might want to consider when building a product backlog within VSTS.

Share This: