powerobjects: Measuring Effort

[Blog bot]

Источник: https://www.powerobjects.com/2018/05...suring-effort/
==============


Agile methodology can be an excellent choice when managing Dynamics 365 implementations. With the use of user stories and requirements, a common question can be how much time will this take? Understanding this is crucial in determining the ROI (Return on Investment) for an ask. Given the importance of time and accurate estimation, how do we figure this out? We need to break down the functionality into User Stories or Requirements. Which one should you use?

User Stories vs. Requirements

With an Agile project, we like to gather User Stories as opposed to Requirements. Think of a story as more of a functionality goal that a user is trying to achieve, whereas a requirement is a more detailed breakdown of how specific functionality should work. Since the specifics are not fully gathered at the User Story level, we use Effort, not hours, as a means of estimation. So, what is Effort and how do we translate that into the hour estimate?

Effort

Before diving into effort, we must first define the two components that make it up; complexity and size. Complexity is __________. Size is __________. We like to measure both Complexity and Size on a scale of 1 through 5. While the value of a 1 or 5 may vary depending upon the project, we use the below as a general guide.

Complexity

1. Clear with no dependencies or research required.
2. Easily understood and not very technical with minimal dependencies with little to no research.
3. Moderately complex and technical with few dependencies, requiring little research.
4. Very complex and technical with multiple dependencies, requiring further research.
5. Extremely complex and technical with many dependencies, requiring further research.

Size

1. Very small story representing little time required.
2. Small story representing a small amount of time required.
3. Moderate story representing a modest amount of time required.
4. Large story representing a large amount of time required.
5. Extremely large story representing a great amount of time required.

Now that we have defined complexity and size, we can discuss effort. Effort is Complexity multiplied by Size. Alternatively, for those who like equations, Effort = Complexity * Size. A 1 of each in complexity and size can be easily translated into an hour estimate. However, as these numbers get bigger, accurate estimation can become much more difficult to achieve. The larger the story, the more concern there is in making estimates less accurate. This is where the Fibonacci Sequence often comes into play with Agile projects.

Fibonacci Sequence

Many Agile projects use the Fibonacci sequence as a method of measuring effort because it intentionally creates a lack of precision so you don’t get hung up on trying to produce accurate estimates. The Fibonacci Sequence begins with “1, 2” and all subsequent numbers are the sum of the two preceding, as follows: 1, 2, 3, 5, 8, 13, 21, 34, 55. This can be difficult for many people to understand. It can even get confused with representing an hour estimate. So how do we intentionally measure effort with a low degree of precision? We use what is rather universally understood: T-Shirt Sizing.

T-Shirt Sizing

T-Shirt Sizing is a very simple concept. Most people understand the idea of sizing a t-shirt. So, we measure all User Stories on a scale from XS to XL. This gives us five distinct values which also happen to line up with how we measure Complexity and Size. Remember, Effort = Complexity * Size. Let’s look at this using a matrix.



Now we can translate this into our T-Shirt sizes.



Admittedly, it’s not the prettiest color scheme, but it gets the point across. If you ever have any User Stories that are sized XL, then there is a chance you may not be getting specific enough and the story should be broken up into multiple User Stories. In addition, if you have far too many XS User Stories, you may be getting too granular with your stories. When you start to get too granular, you want to consider using Tasks. What are Tasks? We’re so glad you asked!

Tasks

A User Story can have multiple Tasks beneath it. This is where you get into the details and requirement gathering. Again, the User Story is the functional goal you are trying to achieve. Requirements are the detailed breakdown of how that functionality will work. Even with Agile, we still need to gather requirements. We just don’t gather them all at once in the very beginning. This is what helps add flexibility to the project.

Requirements will be handled with Tasks. By breaking down the stories into individual tasks, you should be at a small enough level where you can now provide hour estimates. Roll up all your Tasks, and you will now have a more accurate hour estimate for each story. This is great for those who want to consider the ROI on all requests.

Bringing it all Together

So how do we gather requirements and provide specific hour estimates in an Agile project? We start by gathering functionality requests from users and putting them into stories. Based on the story, we can estimate the level of complexity and size and translate that into Effort measured by T-Shirt size. When the time comes to start working on a specific story, we will work with the SME (Subject Matter Expert) and begin putting together the requirements. These requirements are broken up into Tasks which will be assigned an hour estimate. By summing all the Task hour estimates under a story, you will get a total hour estimate for that functionality request.

Looking for tips and tricks related to Dynamics 365? Be sure to subscribe to our blog!



Источник: https://www.powerobjects.com/2018/05...suring-effort/