Agile Foundations - getting to Done

What is the guiding purpose of our project? What statement holds the cloud of requirements together?

Remember the word 'PIPE'? What does it stand for?

__Principals__ (hint - think $)

__Insiders__

__Partners__

__End__ __Users__

What seperates good stories from bad? In this mode we will cover William Wake's INVEST mneumonic, and how it can apply to your requirements.

This quiz confirms you know how to write requirements in the form of a good User Story.

This module shows how to rank what gets done first, next, or not at all!

Customer Value and effort to build something may be different. Let's focus our business people on setting the priorities, and show how the engineers and team can quickly estimate so we'll be ready for planning.

Learn how Agile teams get everyone's input to produce quick and effective estimates.

How much can we do? This module shows how decide how much we commit to, how many things are "stretch goals", and what has to wait for next time.

Okay, everything has been building up to this point. It's time to sketch our plan so we can later effectively take action if things are falling behind.

How much will fit in our plan? What is the concept of 'Speed buffer?'

These final details help you select and adapt the right process for you. 1? 10? 100?

We wrap up our planning module by showing how to view multiple teams, and how to avoid 4 deadly mistakes.

You've sketch out your big picture release plan. Another couple of weeks have passed, and now it's time to another iteration. Here is a checklist to get you started.

Quality is key to keeping our team running efficiently and to delighting our customers. How can we do our work efficiently and build quality into the way we work?

"Big Visible Indicators" - "Information Radiators" are terms you may hear that describe the workspace of an alert Agile team..

At the end of our two week slice we demonstrate our work so we can be sure we got it right. If any changes are needed we can decide if we should include them later. Customer feedback helps us build the right thing.

We also get the team's feedback on how we can tune our process to work smoother in the next two weeks. After a few years of doing that you will have a well oiled machine!

What went wrong? Or really, how can things go better? Retrospectives help the people doing the work find improvements to streamline their work. Imagine the cumulative effect of 2 improvements every two weeks for a year! Here's how.

Let's learn by doing. Create some imagined problems for your team, and illustrate how they would show up in your graphs.

Practice sustainable pace as you repeat each sprint and release. Energized knowledge workers produce more. Overly stressed ones produce defects.

How do testers serve an Agile team to build quality in?

Some of the theory behind our agile techniques comes form a century of industrial engineers looking for ways to work more efficiently. By seeing the past, we get a feel for some of the reasons behind the Agile practices we've learned.

One of the biggest problems I've seen with teams over the years is not the planning or engineering, but hidden conflicts. By knowing folks may see the same issue though different styles we can avoid some common problems that can make work harder than it needs to be.