Kevin Tolva is a senior management consultant with Kenway Consulting in Chicago, Illinois. He focuses on developing, and implementing leading edge solutions that take advantage of critical business opportunities. Kevin's true passion is agile development methodologies and is a recognized leader in the field. He's coached over 20 teams through their agile adoption journey, and has  authored multiple training courses for Kenway's consulting practice.Show NotesWaterfall project management was predicated on very large sequential steps in order to get delivery. Planning phases with exit criteria, then functional design, coding, testing & deployment. Usually very long phases that got you to an end goal.Waterfall was taking too long to get projects out the doors and a company’s ability to react was impeded by these very long cycles of development. The degree of error gets much larger as you get farther out. The degree of uncertainty is much smaller for the things that you know this week or in two to three weeks.The agile manifesto has been around since the 1970s but the agile manifesto was written in 2001.With agile, the focus is on right sizing of documentation at the right time. By breaking the work down into smaller chunks you can make what you’re defining much more digestible. It doesn’t have to be perfectly defined from the beginning. This shorter cycle allows stakeholders the ability to react and change courses more easily throughout the process. This not only delivers a higher quality product but the features are what are actually wanted and desired.The most popular agile framework is scrum.There is still some amount of planning; sometimes referred to as Sprint 0. After that you have one to many interations or sprints. These iterations are typically one to three weeks. Anything longer than that is closer to waterfall.The first step is a sprint planning meeting where the whole team gets together with the product owner and the product owner has a prioritized list of work they want to do. The developers get a consensus and common understanding of the work that needs to be done and they pull it into the sprint and commit to doing that work within the sprint. At the end of the sprint there is a showcase or demo where the development teams shows off what they’ve gotten done. Repeat and rinse until the work is completed.After the sprint, especially for young teams, is completing a retrospective. This is an opportunity to look at what went wrong, what we need to improve, and then agree on the few things that we really need to focus on to improve as a team. This is critical for young teams in their agile adoption journey.In the beginning you need to build a product backlog. This will be the items that need to be done to get your product out the door. In the beginning having enough stories to fill one or two sprints will be enough to get started. If your backlog is ready the time to get a sprint started will be fairly minimal. Once the backlog is ready, you can begin a sprint planning session. This is typically the product owner, the scrum team, the scrum master and the business analyst deciding what they want to bring into the sprint. During the duration of the sprint it’s really the job of the product owner to answer ad hoc questions.If you’re going by the book, product owners don’t sit in on the daily meetings to allow the team to speak more freely but this is not a hard and fast rule.Typically stories are written by either the product owner of the business analyst. Stories don’t have to be all that complicated are typically contain who (the actor), what needs to get done, and the result of the story. Typically this is a very small piece of work. The acceptance criteria is very granular. You have to make sure the acceptance criteria is not subjective.Stories should be written in the business voice rather than the technical voice. The technical details get brought in during the sprint...