Rusty Divine

Live, Love, Learn, Teach

Evaluation Results from my Presentation

I recently presented at Nebraska Code Camp for “An Agile Requirements Gathering Process to get to MVP” and my session evaluations are back!

Getting feed back is something I look forward to because I put a lot of work into what I do and I always am looking to improve.

An improvement I see based on talking with attendees and reviewing the evaluations is that I could have done a better job explaining some of the agile terminology and philosophies that I discussed during the presentation so that attendees less familiar with it would have had an easier time following along.

Based on 8 evaluations, out of I would estimate 30 attendees, here are my average scores on a scale of 1 = Terrible and 5 = Great:

  • Preparation: 4.63
  • Clarity: 4.75
  • Content: 4.5
  • Demos: 4.5
  • Use of Time: 4.75


  • Liked effective real world use. Practical tips usable inf9
  • Overall, great, well prepared presentation. Consider slowing down a little. This did allow for a lot of well facilitated discussion time though!
  • Rusty provided a wonderfully clear process that can be multiplied across numerous organizations and projects. The presentation was easy to follow and understand, especially because of the example he provided. I really enjoyed this presentation!
  • Very useful want to do a user group on this topic
  • More concrete demos would be nice. Also maybe some agile introduction.

Thanks to everyone who came, to those who helped me prepare, and to the attendees who took the time to leave me some feedback.

Defining the Slides for my Agile Requirements Gathering Talk

Previously, I outlined my talk into seven six-minute sections, with a three-minute intro and outro. That’s 48 minutes, which is good, but I found out that the talk is supposed to be 45 minutes and I’d rather leave time to have a question or two at the end than run over. If I did seven five-minute sections, it would work out a bit better.

This revelation hasn’t affected my outline - I haven’t cut out any of the points yet. I feel like there is still too much there, and some of it may not support my main idea of showing the audience how we did this type of assessment, but I’m more comfortable risking developing slides and notes that I’ll later cut out than pre-optimizing the talk.

I have a theme chosen for the slides (one of the default themes for PowerPoint 2013), and my working list of slides is:


  1. p0  Title Slide
  2. p1,2 The old way (how it used to be)
  3. p1,2  Idea vs. Problem (what it works well for, and doesn’t)
  4. p3  How to sell it to stakeholders (both $ and rationale)
  5. p3  Preparation for the meeting
  6. p4  Where’s the Fruit (idea of the app we’ll walk through)
  7. p4  Assessment Agenda (describe different parts)
  8. p5  User Stories (how to collect and record)
  9. p5  WTF’s example stories
  10. p5  Constraints & Assumptions
  11. p6  Getting priority & CFS/MVP agreement
  12. p6  Whew. Retro time
  13. p7  Checklist of what’s left to do
  14. p7  Running a project (burn down/agile)
  15. p8  Thanks, contact info, questions

Fifteen slides at an average of three minutes per slide seems about right to me. Adam had an interesting suggestion – he wondered if assigning planning poker points to each section would help estimate how big that section was. I think this could work for the slides, too.

Next: design the slides. I’d like to include some animation (content coming in/out of a slide) and stock photography balanced with my main points in text. I’d like to stay pretty light on text and try to focus on things that will grab the audience’s attention and keep it. I’d like to try throwing something into the middle that breaks the norm to keep them engaged. Around slide 8, the half-way-point, I’ll ask for a little audience participation to suggest a user story for WTF – I’ll need to be careful to time box that experiment so that I don’t run over.

Outline for Upcoming Talk on Getting to Minimum Viable Product (MVP)

On the last Saturday of March, I’ll be giving a talk at Nebraska Code Camp titled, “An Agile Requirements Gathering Process to get to MVP.” My progress will be shared here on this blog, and ultimately, the slides and maybe even a video of my presentation will be available.

The talk covers the experience Keil, Adam, and I had using a requirements gathering process we adapted. The big idea is:

An agile assessment process can help stakeholders define and agree on the vision for a project, the most important features and their priorities, and help prevent developing something that strays off target.

I want each slide in the presentation to support that idea if it can so that the message sticks. Having the one big point to make helps me determine how to prune and focus the talk.

7 sheets of paper * 6 mins per sheet is a great way to plan a talk. Hat-tip @shanselman, @john_papa, @pluralsightI started out with a stack of sticky notes, each with its own thought. Next, I decided that if I divided the presentation into seven six-minute talks, plus an introduction and conclusion, then I could more easily determine how to pace the talk and define its structure. I took seven sheets of paper, and organized the sticky notes onto them.

Today I took each page and thought about the main reason for each, then created an outline with notes about the ideas I had. I started combining and separating the notes on different pages, moving them around, and identifying some I hadn’t thought of.

The outline is posted below so that Keil and Adam, or anyone really, can comment on it and help me to clarify it. I feel like I have too much content here, so using the big idea above for reference, I should be able to pull some out – for instance, talking about how to sell an assessment while handy doesn’t really support the big idea. I’ve left that in for now to help show the process.

I want to include as much showing of the process as opposed to telling about it as possible, so I am going to be walking through the assessment of an app called “Where’s the Fruit” (WTF). Adam and I have already done an assessment on this app, which we did to help show off the process to potential customers.

I’ve been using the Pomodoro technique (just the timer) while working on this presentation, and that’s really helped me focus. My next step will be to start creating the slide deck using some tips from Pluralsight (John & Scott), Scott Adams, and Rexi Media.

Part 0 - Intro

- Introduction, welcome

- Talk about what’s in it for the audience (story/reward), provoke curiosity

- brief overview

Part 1&2 - Answer Why

- Story of how we were doing things before this method. Good and bad. Ask audience if they've can relate.

     - Tell me how much this project will cost after this 30min meeting; book review analogy

     - There is no such thing as a simple app

- Story of how we learned about this process from someone in our peer group.

- Why it works for consulting projects

     - Balance between full agile and waterfall; a middle-ground for establishing trust

     - Weed out customers who won't even pay for the requirements gathering. Story of D.S..

      - Client/Stakeholder empowerment through driving the requirements  

     - Budgeting needs

          - Fixed price vs. T&M

- What does it not work well for

     - "I have a problem"

     - Migrating one system to another

     - Integrating one system to another

- What does it work well for

     - "I have an idea"

     - greenfield

     - Getting multiple stakeholders to agree on the vision and priority. Need as many stakeholders in the room as possible, and devs, too, so they can get in on the vision from the ground floor.

     - Getting the core feature set determined (aka mvp)

Part 3 - Selling & Preparation

- Simple to sell a fixed-price product vs a T&M project

- This process, or something like it, is something we have to do anyway. We're just pulling it out and putting it in front.

- Gives customer a chance to work with us with a small risk

     - At the end of the assessment, they can take it and shop it around or continue with us

- We don't validate the business idea, but could give them some feed back as a SWOT

- Consider having a plan for handling conflict between stakeholders and practicing.

- To prepare

     - Send customer information about the process and what to bring and what to expect. The more work they put in up front, the better.

     - Setup the room, preferably one that is very large and has a large white board or two or wall board paint

     - Put the agenda and rules up

     - refreshments and name cards ready

     - sticky notes for story titles

     - One note taker, one facilitator

     - Try to do between meals

Part 4 - Getting Started

- We are going to walk through a mock product - where's the fruit

- We don’t know the budget or schedule, customers don’t like to tell us that up front (trust)

- Talk through the agenda

     - Never feels like enough time, but we make due

- Define the objective

     - what makes a good objective

          - SMART, derived from narrative, like an epoch; could have a so that

     - edit it as needed throughout the day

     - WTF's objective revealed and dissected

- Users and Roles

     - Admin users

     - end users of different types (don't get too stuck on these)

     - system integrations

     - report users

     - these become the actors in the user stories and can provide a check point during the meeting to see if we've captured the main stories for each user

Part 5 - User Stories

- User stories format

     - format of a user story

     - why the so that is so important

     - look out for circular reasoning

     - conditions of acceptance

     - consider admin tasks; back-end user & data management

     - consider the long haul; archiving, cleaning, moderating, reporting

     - have customer describe the workflow they envision as if they were sitting down to use the app

     - easy to overlook stories about security, exports, logging, reporting - some of these can be added in after the assessment during the research

- User story examples

     - WTF's examples

     - Get the audience to throw one out

- Write down constraints and assumptions as they come out

     - show WTF's examples

- Diagram and mockup as necessary, but beware of spending a lot of time there

Part 6 - Defining the core feature set

- Good time for a break to get people's mind a rest

- Put all the sticky notes of feature titles onto the wall

- Have stakeholders take turns organizing them into what is most important first

     - guidance is needed to give them context

     - Importance does not equal darling

     - Which feature is more important than another in context of having a functioning application

     - Can't put stories at the same level; can nest them if they really are related, but otherwise have to decide if one of these stories wouldn't get done, which one would I rather get done

- After everyone is satisfied, it's time to draw the core feature set line

     - Sometimes this is hard for customers who want it all

     - We need to determine what has to be there for the system to stand up on its own

     - We can and should add more later; priorities will shift, new ideas gained, old ones discarded.

     - What we find is the target has moved by the time we get that small set finished, so aiming to do more than that will often waste time, effort, money.

- That's a wrap. Now, we're all exhausted and don't plan on doing anything else productive.

- One more thing to do - a meeting retro. We did this without the customers sometimes and with them sometimes.

Part 7 - Post Assessment

- Off-the-shelf research - is anyone else already doing this; can we integrate?

- How we point stories

     - filling in any missing stories

- Assembling deliverable

     - creating some mockups, workflow sketches

     - tools: PowerPoint w/mockups,

     - lean canvas and/or SWOT

     - Proposal with fixed price, first available start date, stories and their sizes down to CFS

          - project scope & price is more about sum of user points; customer can swap in/out stories as long as total points are same

     - how to convert points to dollars

- Running a project

     - two-week iterations, burn down, daily stand up with customer, demo/retro, customer prioritizes and manages scope, change requests


- You can use this process for your own ideas, or for customers

- It is a great way to brainstorm features, get agreement among stake holders, and get everyone in the room on the same vision

- Get the slides and more information from my blog, and feel free to contact me

- Questions?