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, what Kanban is, and what a project is. You will also learn more about iterative development, and 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 deliver 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 you 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 requirement. 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 or at the start of a project, is that you let them know that you won't be able to give them accurate dates, times, costs, etc. For exactly when the project will be delivered until the end of at least the inception stage. Instead, you need to say, we're going to work iteratively on incremental way to deliver you some of the project as we do that, we'll be able to really get a stronger idea of exactly how much longer will take us to complete the project.
When you're estimating, it's extremely important that you do so in a relative way rather than an absolute way. Have a look at these three cubes for instance. I can't tell you anything about them absolutely, other than, they're cubes. But I can tell you that the cube on the furthest right seems to be the largest one, and the one on the farthest 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's easy for me to estimate the cube size relative to each other, but if you ask 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 requirements. We can discuss a project, compared with the work we've 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 brought before you 10 people of different sizes, different body matters, and asked you to estimate their body mass, wouldn't be able to do that with any degree of precision and there's a reason for that. Humans aren't designed to be able to, tap in with any degree of precision, people's body mass, and that is because you have to take into consideration the height, and it's difficult to estimate that, you know, visually their weight and then complete that into a body mass estimate. But if I were to ask you to, sort of grade, every single person of those 10 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 kinds 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 our capacity and velocity as a team. One of the best ways to give our requirements and 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 versus smaller ones more easily. Every number in the Fibonacci sequence is the sum of the two previous numbers, so, one, two, three, five, eight, 13, 21, etc. It's worth noting that planning poker games sometimes use an alternate sequence, that's pretty much the same, except that it goes to 20, not 21. And from 20, it goes up to 40, and then 100. It still roughly follows the same sequence and serves the same purpose. So, maybe we agreed that our smallest cube is one and our largest 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 talk about 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 really quite simple actually, everyone in the team gets a set of cards with a Fibonacci sequence on it. The stakeholder or product owner will present the requirements to us and each person will use their cards to vote for how much effort they think is involved to complete it. There will probably be some difference between the team on this, so we need to discuss it amongst ourselves, and then vote again until we can come to 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 going forward. Planning poker is a great way to go about your estimations as it promotes collaboration and joint responsibility for the work we can do as an agile team.
Tony has over 20 years’ experience in Business Development, Business Change, Consulting, and Project/Program Management working with public, private, and third sector organizations.
He has helped organizations to design and create processes and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider, utilizing 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, Program 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 the director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.