Agile Projects are adaptive and fast moving. To be successful with Agile, you need to follow some simple planning steps to keep the project on track. There are only a few simple practices, but it's important to understand these practices and follow them correctly. We'll start this course by introducing the Agile Sprints. Working in sprints is a significant departure from traditional projects.Next, we'll see how to create an Agile User Story. These stories are the centerpiece of Agile planning. I'll demonstrate how to estimate each story and then roll them up into a planned sprint.
Finally, we'll take these estimates and demonstrate how you calculate your team's velocity. That way you can create a release schedule for your final product delivery. Whether your a Project Manager, a Software Developer, or a Senior Manager, this course is designed to help you get greater agility from your team. So let's get started planning your project with Agile User Stories.
An Agile project builds up working software every sprint. In this section we will teach you how to deliver a agile project in a predictable way.
User stories are critical to successful agile project estimation. Its amazing how much your team can grow and have better estimation through great project estimation.
In this section we will go over how to remove the uncertainty of projects by breaking down your project deliverables into smaller and smaller user stories.
The first step in every project is define the roles and responsibilities in the project. This is regardless of the project being waterfall or agile. In this section we will go through the user roles and how they relate to agile projects.
In the section we are going to review the how to create successful user stories.
In the is section we are going to take the great user stories you learned to create in the previous section and take those to produce accurate predictable results.
Theme or epic is a way to organize stories into groups. Epics are usually created after the stories. It's a way to organize similar stories into appropriate workstreams. In this section we will learn how to use these to your advantage.
An Agile Charter should be an agreement and not a plan. It should list what every party wants from the project. That doesn't mean that things won't change, what it does record is what everyone was thinking at the time the project started. Setting up a good project charter is an essential part of closing out the project. At some point the product backlog will be exhausted, the project will either run out of money, or deliver all the value the customer requested. At that time the team will hold their final retrospective.
From an Agile perspective not doing something is the fastest way to get it done. An Agile team goes back to the technique used by our early ancestors. The team won't think in hours, days, or weeks, they'll think in relative sizing. Is this user story bigger than a bear? Maybe it's smaller than a fish. Relative estimating compares what you don't know against what you do know.
Planning poker is a card game that helps the team get the best story estimates with less than perfect information. The game assumes that everyone on the team is an expert. As experts, not everyone will agree on how long it takes to deliver each story. There's wisdom in the whole team. Planning poker helps give everyone a voice. Some developers might decide the story is more complex. Another developer might think that the story is so small they could finish it up before lunch. There's no way to tell which developer is right until the work begins. In Agile you're not estimating for individuals.
The agile framework pushes back on this ever expanding work week. Agile promotes the idea that people should go home at a reasonable hour. Often developers will think more clearly when they're driving home or walking their dog. An agile project should have a challenging pace, there shouldn't be any project crashes. The team shouldn't have a flurry of activity at the end of the sprint.
Sprint planning is when the team scoops stories out of the product backlog and puts them into the sprint. Some teams will create a separate spring backlog. The sprint backlog is a subset of stories from the product backlog. This backlog will only have the stories to be completed in the sprint. The challenge with the sprint backlog is that it's sometimes tough for everyone on the team to collaborate on a ranked list of stories.
In the past a horse was one of the most valuable possessions you could own. They were your car, truck, bulldozer, and generator. That's why bartering for horses was a serious business. There were festivals for this special event. There were even professions created for quality assurance. Special horse whisperers would even coax out the animal's previous history. Buyers and sellers would gather near the stables and swap out different horses. They could swap out two old ones for one young one. Maybe they'd trade three small ones for one large one. The event was commonly known as horse trading. Centuries later you'll still see groups of people horse trading valuables. Politicians will horse trade votes. Major league sports will horse trade contracts between different cities. Today the event pretty much works the same way. You have a large group of people in a room making real time trade-offs. You'll see the same compromises.
One of the sticking points with new agile teams is deciding what is considered acceptable documentation. Remember from the manifesto that agile projects prioritize working software. That doesn't mean that agile projects produce no documentation. Instead, it should produce just enough documentation. One phrase you might hear with agile projects is they have barely sufficient documentation. Instead, an agile project focuses on working software.
Sometimes with newer agile teams you'll hear them say, "We don't plan because we're agile." This causes a lot of confusion with the rest of the organization. They'll justifiably ask the question, "How can you run a project without any planning?" The truth is you can't. Agile does have planning. It's just different from traditional project management planning. The planning rules are there, but they're just much more lightweight.
I hope you enjoyed this course on Agile estimation and planning. Agile planning is just one of those things that your team will get better with over time. So don't be frustrated if your Agile stories are much less than perfect in your first spread.
Thanks for looking at my courses. I am excited to bring you some awesome lessons I have learned along the way. I also love to talk about my favorite products that really help me stay ahead of the curve. I am an Architect, Developer, Product/Project Manger, and humble hustler focusing on building next generation application.
I am currently working as a Sr. Technical Cross Platform Program Manager at a Fortune 500 company building technology-driven marketing solutions with global reach and Netflix scale. I lead teams of developers to new heights by giving top of the line guidance on product deliverables, organizational techniques, and in general kicking butt. I hope you find my courses enjoyable and please contact me if you have any questions or would like any additional content covered that is not in one of the courses.
I am a PMP expert and PRINCE2 consultant.