Rusty Divine

Live, Love, Learn, Teach

Agile Requirements Gathering Process to Get to Minimum Viable Product (MVP)

Here are the supporting materials for my talk at Nebraska Code Camp (#ncc4) this year:

  1. Slides (PPT)
  2. Assessment Documents
  3. Slides (PDF)

Thanks to everyone who came, and a special thanks to Adam Costenbader & Keil Wilson who helped develop the process and who helped shape this talk through several iterations of creating the outline and slides.

2014 WASP-B Trapshoot League Schedule

Here is the 2014 WASP-B schedule. You can come shoot at any one of these even if that’s the only shoot you decide to try.

April 6: Valley

May 4: Ashland

May 18: Lincoln T&S

June 1: Papillion

July 13: Bellevue

August 17: Nebraska City

September 14: Finals at Valley

All club shoots start at 8am and close at 3pm. Finals start at 8am and close at 2pm.

Here’s some more information about the WASP-B league from a previous post, and they have a website this year, I think for the first time: http://waspbleague.com/

Nebraska Code Camp–Year 4

It’s time for Nebraska Code Camp again! I’m looking forward to Friday’s lab sessions, and Saturday’s break out sessions, which I’ll be speaking for my first time at a code camp for my talk titled “An Agile Requirements Gathering Process to get to MVP”.

We are lucky to get Iris Classon to fly all the way here to be our keynote speaker this year. We had no women speakers submit for a talk, but Iris stepped up and is leading two lab sessions and presenting the keynote, too!

Code Camp is a great chance for developers to network, re-energize by learning about new techniques, and it’s a great place for aspiring developers to get a better feel for what to expect.

Hope to see you there!

How to Enforce Explicit TypeScript Types in Visual Studio 2013

TypeScript has a compiler flag –noImplicitAny to make sure you have explicitly typed all of your variables, even if you type is as “any”.

//With --noImplicitAny flag set, this is OK
class Student {
    fullname: string;
    constructor(public firstname : any, public middleinitial : string, 
        public lastname : string) {
        this.fullname = firstname + " " + middleinitial + " " + lastname;
    }
}

//With --noImplicitAny flag set, this will throw a compile error:

class Student {
    fullname: string;
    constructor(public firstname, public middleinitial, public lastname) {
        this.fullname = firstname + " " + middleinitial + " " + lastname;
    }
}

In order to set this flag in Visual Studio 2013, edit your project’s properties and then in the TypeScript Build menu, uncheck the Allow implicit ‘any’ types.

TS_implicit_any

With the check box unchecked, your compiler will catch any instance where you did not declare the variable type in your TypeScript.

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:

title_slide_mvp

  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

Outro

- 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?