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.

While we recognize that there are allot of creative, non-repetitive, variable work in agile development projects, many work items, ceremonies, and activities can benefit from systematic, reproducible and standardized tasks test and options that can be captured in customizable checklists prepared and used by empowered agile teams.