Engineering/Team Development Workshops/Day 2 notes

Flow Team Development Workshops

August 28-30, 2013

Day 2 Notes

Present: Tomasz Finc, Arthur Richards, Andrew Garrett, Benny Situ, Brandon Harris, Erik Bernhardson, Maryana Pinchuk, Matthias Mullie, May Tee-Galloway, Vibha Bamba, S Page, Gayle Young, Anna Stillwell (guest) Partial attendance: Erik Moeller, Terry Chay, Jared Zimmerman

…

Everybody is a remotely (at some time): e.g. sick, Wikimania, etc.
 * Team Geek - Brian W. Fitzpatrick

User stories User storie A very concise description of a requirement or functionality that has utility to the users has written from the description of the user in everyday language Don’t define implementation details in the user story (part of the free of jargon, every-day language)

Good qualities These are not written in stone, they can bend or break. As a, I can , so that <I can achieve some goal. This causes focusing of user story for clarity and simplicity. Spike Ex of spike in mobile web team. Take Getting Started to work onto mobile Time box of 3 hours. It’s a “spike” in the cost graph. Epic ex. Analytics epic of Workflow Improvements A categorizing tool consisting of multiple stories. storywall Bugzilla How are bugs related to stories. Bugs are defects, not stories. Want to treat them differently, so use a different card type in Mingle. Created a tool called Bingle that acts as a bridge between Mingle and Bugzilla. Whenever a bug is introduce, mingle creates a new card in analysis. (print backlog, not backlog). Backlog A bucket to toss user stories in. There are multiple backlogs. Anyone can create a user story.
 * Independent
 * Negotiable: you should be able to sit down and have chat with someone and be able to discuss what the requirements are to complete the story
 * Valuable to end users: User-focused. They’re called user-stories for a reason. You want to be driving empathy for the users (walk a mile in their shoes). (even between division, "as a mobile developer I want to be able to ……… in analtycis)
 * Estimable: What causes it to not be estimable: 1) people lack domain knowledge- this is an opportunity to have a conversation; 2) Spike? Then get it so they can estimate story; 3) If it’s too big- It is called an “Epic”- try to break it into smaller chunks and get rid of Epic.
 * Small
 * Testable
 * can we use it deliver random tasks on mobile?
 * do we have an additional work to use it?
 * how hard/possible would it be to make it global instead of enwiki only?
 * How hard is it to add new tasks?
 * A very large story, may require a release or multiple releases to complete
 * comprised of numerous small stories
 * Can be useful for categorizing or grouping smalls tories

User story writing workshop (Exercise) Not necessary: Rule of 3? When something needs to be discussed, there are three people: representative of product, engineering, etc. Anyone can write a user story. Try to write them so they’re connected to the persons.

Prioritization (Tomasz) Prioritize all the things!!!! (Hyperbole and a half) Exercise: prioritize cards based on MSCW framework. Prioritization is not a one-time activity, it’s a constant activity Ruthlessly prioritize all of the time, all of the things. This makes time boxing more effective because you make sure you work on the high priority items.
 * Risk involve * scheduling * community * functional
 * effort of development
 * value/desirability of features * MoSCoW framework: Must Have, Should Have, Could Have, Won’t Have

Estimation “S”timate! Want user stories to be estimable. Relative estimation: relative size (on difficulty of the story vs. hours). Estimation is shared Estimation scale: This gives you velocity over time: Burndown chart: Burnup chart Effective tool to say when it will done, or… tell them to stop adding scope (combat scope creep). Great for Fundraiser because launch date was fixed. Planning Poker: Exercise that makes estimation easier and more fun. Find extremes and continue conversation and repeat until the numbers are close enough. When you have dependencies you want to avoid them by either breaking them into discrete chunks, combine cards, etc. To establish baseline. Find something that represents a 1 and measure everything relative to that. With remote folks: http://hat.jit.su (mountain goat software) Estimation practice:
 * engineers are bad at hours
 * it’s easier to guess on log scale
 * Estimation owned by the team - to individuals
 * Done by engineers, with product present: Other stakeholders in room, but must have is product
 * Fibonacci: 1 2 3 5 8 13
 * x1000: to make your team badass
 * Whatever you want: can use dog breed sizes
 * avg story points completed
 * corrects estimation errors
 * what’s happen before is a good predictor of what will happen again
 * useful for capacity planning
 * Make predictions of when you are going to be done.
 * track scope on one line
 * track story points completed on days
 * Get cards
 * talk about it
 * select a card face down
 * then everyone shows their card

Scrum rituals

Daily retrospective What worked well? What didn't? What still puzzles you? ??
 * Showcase, she now knows what is going on (interfacing conversation)
 * Real cards with real rings, and we can proceed forward
 * Writing out the user stories, think it worked well: practicing story writing
 * The whole concept of agile making you focus what’s being swept under rug came out today
 * Time we spend applying principles for real work is real effective.
 * User stories: Did a lot of duplicated effort (and wrote same things)
 * not enough broad engagement (too much Brandon’s baby)
 * planning poker: different foundations means have yet to have a successful round.
 * cards don’t look actionable items to story cards: acceptance criteria, design, etc.

Parking Lot
 * BA & Community Liaison conversation: Maryana is owning it
 * Remote participation for the Flow team (Andrew): have Aus, Belgium + CA; either 1) distribute pain equally, 2) i18n team does all their planning in one day but async after that; some of this stuff can be async (via e-mail). It canary, consistency is key: Andrew Garret is owning it
 * Where are we? (Tomasz): Where are we in the development cycle in the project. Answered with the showcase