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.
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.
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
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.
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.
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
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.
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.
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.
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.