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

having the right size for backlog items and tasks is crucial for a smooth and successful sprint delivery. agile and scrum are user story or product backlog item (pbi) driven approaches and are overcoming some of the major notches in delivering the product that customers want.

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 the most efficient way . this implicates that communication and understanding the requirements is crucial in delivering the product that the customer has actually envisioned.

requirements in an agile world

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 the use of vsts .

product planning

the first step that you want to take 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, the high-level plan and, later on, more detailed requirements in order to be 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, small, and testable (among other criteria) , it should be considered as an 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 are no dependencies and that this item can be used as a completely independent piece of product with its full functionality.

having this in mind and if you have already dealt with the structure of the 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 also be able to add additional levels to your product backlog. please see the picture below for more insights on the levels and structure that can be adjusted in vsts. in total, you can have seven levels, starting from the very top and going to the task level.

sprint planning

once when you have reached 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 into 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 a certain part of a user story. in this case, slicing the user story into a task will be the fastest and most efficient way to deliver it.

in vsts, using an agile approach we usually use tasks as items that can be delivered within hours and that are shared between different developers.

task -> hours

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 usually have 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. a crucial point here is that the team needs to understand all the work items in order to be able to estimate 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 scales like the fibonacci sequence , t-shirt sizes (xs, s, m, l, xl, xxl) or even a custom-made scale.

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 to the estimation part. as the extension is a part of vsts, it will automatically transfer the agreed story points directly to the work items.

conclusion

every project should, of course, have a 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 might want to consider when building a product backlog within vsts.

further reading

how to apply scrum to your software development company

in sprint planning, how do you prioritize the requirements in the backlog?