Described below is the agenda for tomorrow's meeting. It's brand new and more Scrumptious than ever! (http://instantrimshot.com)

Story Points

In Scrum, each user story is given a certain number of "story points". These points represent how complex the story is. A story like "As a user, I want to read the site footer" might have 2 story points. A story like "As an administrator, I want to generate a spreadsheet of user information" might have a 100 story points. Story points are usually measured on the Cohn scale: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Story points are unit-less.

Keep in mind that story points do not measure how long it will take to complete a task (that is done differently). Instead, story points measure value to the customer. Imagine that a team accomplishes 100 man-hours of work in a given week. Did it take that long because the software was groundbreaking and complex, or because the team had trouble coordinating their efforts? The statistic does not make it clear.

At this point in the meeting, the team will assign story points to each of the tasks in the Product Backlog.

Priorities

In Scrum, every user story is given a priority. When the team meets to plan a Sprint (that's what we're doing today), it selects the top priority items from the product backlog and commits to building them within the next Sprint.

At this point in the meeting, the team will assign priorities to each of the items in the product backlog.

The What: Designing 0.9.6 and Assigning Tasks

In Scrum, the result of a Sprint should be carefully designed. As I write in the Scrum Guide...

The resulting product should not be just "a thing that does voting" and "a thing that does log-in" and "a thing that does photo upload". Instead, the final product should be something like "A system that allows the user to log in, post photos, view content, and vote on the content that exists."

At this point in the meeting, the team will carefully decide what user stories it will work on (based on priorities) and carefully design the software that will exist at the end of the Sprint.

The How: Implementing 0.9.6

At this point in the meeting, the team will discuss how to implement the user stories it has committed to.

Short Status Updates (about 15 minutes)

At this point in the meeting, the team will hold its usual Daily Scrum.

We will do this in person, so written status updates are not necessary. As some status updates were written before this page was reorganized, they are provided below.

Luke Retro

sucks:

• stage9
• ISE on submit page not caught by tests ...

awesome:

• standups
• more time coding
• expanding test coverage
  • @mockdekiauth decorator

Jay Retro

bad:

• when i think we're done with something, i get more feedback from mgmt on how we can do more (will need to figure out a sane way to introduce these "ideas" into future releases without sacrificing current goals/milestones.
• extended downtime during push needs a 500 page for ISE scenarios
• spreading design resources really thin during end of quarter crunch time (we should make sure craig and chowse don't get burned out)

good:

• agile strategy taking shape; daily standups are helpful; close to executing on our plan to use stories to plan out milestones
• successful launch of dev derby (feedback has been very positive) and promote mdn (except for the alt= bug, it's looking promising)
• excited to see Kuma editor UI take shape and get docs community testing on it (let's make sure we knock it out for 0.9.6)

Misc

Other notes that were written before this page was reorganized are provided below.

Triage

http://mzl.la/j6LLCv

• bug 661358 - fix relative paths in css
• bug 661307 - 500 on /pl/demos/detail

MDN 0.9.6