Engineering/Team Development Workshops/Day 2 notes

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

…

Team Geek - Brian W. Fitzpatrick

Everybody is a remotely (at some time): e.g. sick, Wikimania, etc.

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

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

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

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?

Time box of 3 hours. It’s a “spike” in the cost graph. Epic

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

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.

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)

Risk involve * scheduling * community * functional
effort of development
value/desirability of features * MoSCoW framework: Must Have, Should Have, Could Have, Won’t Have

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.

Estimation “S”timate! Want user stories to be estimable. Relative estimation: relative size (on difficulty of the story vs. hours).

engineers are bad at hours
it’s easier to guess on log scale

Estimation is shared

Estimation owned by the team - to individuals
Done by engineers, with product present: Other stakeholders in room, but must have is product

Estimation scale:

Fibonacci: 1 2 3 5 8 13
x1000: to make your team badass
Whatever you want: can use dog breed sizes

This gives you velocity over time:

avg story points completed
corrects estimation errors
what’s happen before is a good predictor of what will happen again
useful for capacity planning

Burndown chart:

Make predictions of when you are going to be done.

Burnup chart

track scope on one line
track story points completed on days

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.

Get cards
talk about it
select a card face down
then everyone shows their card

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:

Scrum rituals

Daily retrospective What worked well?

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.

What didn't?

User stories: Did a lot of duplicated effort (and wrote same things)
not enough broad engagement (too much Brandon’s baby)

What still puzzles you?

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