Agile Foundations - getting to Done

4 types of stakeholders

Personae

Standards covered

IC13-4.1 - Including Customers & Users

PM11-D2.1 - Stakeholder Needs

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

How can we best describe requirements so they are clear to the customer and to our team?

User Stories are the basic building blocks of Agile projects.

• Epic / Feature / Story / (task)
• 3 C's
• RGB
• Product Box

Learning Card Activity:

1. Write a story.
2. Read 2 others

Grade yourself:

• 5 points - has 3Cs and RGB
• 7 points - has INVEST
• 9 points - small

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.

What comes first? After this module you will have specific tools to help you prioritize your list of work, which is key to Agile.

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 big are the things we are working on? Here is a good way to estimate our work so we can plan better.

Don't stress too much about getting it perfect the first time. After 3 to 5 iterations your estimates will become more consistent. Before that any more thinking is s waste of time. We really just don't know until we get into this technology with this team. But with experience our estimates become very accurate. It is common for them to be off by 60% for brand new team, and to converge to be within 15% after a few sprints.

This graph shows the actual hours per 'story point' varies at the beginning for this team, but then not only becomes more consistent, but more productive (fewer hours needed to finish each story point)

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?

The daily stand-up meeting is a key driver for collaboration in the coming day.

"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.