Agile Fundamentals Online Learning
The course is part of these learning paths
This course takes a look at how you can work in an agile way. It will help you to understand what value is, how to measure progress and what Kanban is, and what a project is. You will also learn more about iterative development, how to estimate, and reflect on your own agile journey.
The objectives of this course are to provide you with and understanding of:
- What value is
- How to measure progress
- What Kanban is
- What agile pm/ DSDM is
- How to delivery in an iterative way
- How to estimate
- Growth through mastery
This course is suitable for anyone with no prior knowledge of agile who is considering, evaluating or involved in a move towards working in (or with) an agile environment.
There are no prerequisites for this course, however, participants should be familiar with the content and rationale in the agile manifesto (http://agilemanifesto.org/ )
We welcome all feedback and suggestions - please contact us at email@example.com if you are unsure about where to start or if would like help getting started.
To work in an agile way, we have to be able to estimate the amount of effort required to complete any user story. But, how do we do this? Well, the first thing to remember is that an estimation is always, at its best, really just a guess. If we look at Steve McConnell's Cone of Uncertainty, which plots time against the error of estimation, we can see that initially, we will probably have a very large variation between the highest estimation and the lowest estimation. Over time, as we deliver increments, our estimations will become much more accurate.
So, the key thing then is, whenever you work with stakeholders at the start of a project, you must let them know that you won't be able to give them definitive dates, time, costs, etc., for exactly when the project will be delivered. Instead, you need to say, "We are going to work iteratively in an incremental way to deliver you some of this project and as we do that, we'll be able to really get a stronger idea of exactly how much longer it will take us to complete the project."
When you are estimating, it is extremely important that you do so in a relative way rather than in an absolute way. Have a look at these three cubes, for instance. I can't tell you anything about them absolutely, other than that they are cubes. But I can tell you that the cube on the furthest right seems to be the largest and the one on the furthest left seems to be the smallest. I can even say that the biggest cube seems to be about four times as large as the smallest one. It is easy for me to estimate the cube size relative to each other but if you asked me how much the smallest cube weighed absolutely in kilos or pounds, I don't have the information to tell you this. All I can say is that it looks about four times less than the biggest cube. We can easily apply this relative estimation to our user stories. We can discuss a project, compare it with what we have done before, and estimate how large it is based on this.
Okay. So, the question is about relative estimation versus absolute estimation. Well, if I was to put before you ten people of different sizes, different body masses, and asked you to estimate their body mass, you wouldn't be able to do that with any degree of precision, and there is a reason for that. The human... humans aren't designed to be able to determine with any degree of precision people's body mass, and that is because you would have to take into consideration their height, which again, is difficult, to estimate visually their weight and then compute that into a body mass estimate. But if I were to ask you to sort of grade every single person of those ten people in terms of their average body size, in terms of small, medium, large, you would be able to do that, and that is because people can, you know, are able to make those kind of estimates because it doesn't require precision.
The next thing we need to do is attach numbers to our estimations. This is really helpful when it comes to figuring out what our capacity is as a team, which is called our velocity. I'll talk more about velocity in a moment, but for now, let's focus on how you can go about attaching numbers to our user stories.
One of the best ways to give our user stories an estimation in numeric form is to use the Fibonacci Sequence. This is because the sequence gets exponentially bigger the further up it goes, helping us to represent larger projects vs smaller ones, more easily, and help us know when we won't be able to complete work quickly.
Every number in the Fibonacci Sequence is the sum of the two previous numbers; so, one, two, three, five, eight, thirteen, twenty-one, and so on. So, maybe we agree that our smallest cube is a one and our largest cube is an eight. Going forward, we now have a benchmark to estimate all cubes we encounter or, in work terms, we have a way to put a number that represents the effort it will take for us to complete that work.
Great, so let's go back to the idea I mentioned earlier: velocity. Velocity is simply the number of points we get done in a specific time. Let's say two weeks. Maybe our velocity is 200. If we go into sprint planning and come out with a sprint backlog that has 250 points in it, we should know that we have overestimated how much we will be able to do, which means some of that work probably won't get done. We should only ever plan to work on as much as our current velocity allows for. Once our velocity is set and steady, we can also start to have a better idea of exactly when a project is likely to end.
A great way to go about your estimation is, to play a bit of Planning Poker. So this is actually really quite simple. Everyone on the team gets a set of cards with the Fibonacci Sequence on it. The stakeholder, or product owner, will present the user story to us, and then each person will use their cards to vote for how much effort they think is involved in that user story. There will probably be some difference between the team on this, so we need to discuss it among ourselves and then vote again until we can come as close to a unanimous vote as possible. This method allows the whole team to understand what the work entails and to collaborate on understanding and estimating rather than this sitting with one or two members of the team.
So, yes that's that for this video. Estimation is just about a relative number you can use to understand the effort required in doing something. Relative estimation allows us to be as accurate as we can be, but still gives us the flexibility to change over time. It also helps us to build a velocity, which helps us to plan our work over time. Planning Poker is a great way to go about your estimations as it promotes collaboration and joint responsibility for the work we do as an agile team.
About the Author
Tony has over 20 years’ experience in Business Development, Business Change, Consulting and Project/Programme Management working with public, private and third sector organisations.
He has helped organisations to design and create process and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider utilising a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.
As a confident and self-motivated professional with excellent communication skills Tony is able to bring people together and get them working as a team quickly.
Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Programme and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers and worked at Director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.