Page History

...

Communication

• Stand-ups occur daily at 810:45 00 AM on the ECHO conference line.. (877) 847-0013,8518026#
• Sprint planning meetings occur as part of the EED2 SAFe efforts. Typically on the first day of each sprintSprint planning occurs every second Friday from 10:00AM - 11:00AM over GoToMeeting.
• Retrospectives and sprint overviews take place on the Friday before the start of the sprint.
• Developers should use NASA Jabber accounts for chat and join the Jabber group chat earthdatadev@conferenceedsc@conference.im.nasa.gov. Developers use Messages or Screen Hero for remote screen sharing.

...

We have short daily stand-ups near the start of the work day (8:45 AM) to give status and note any problems.

...

Estimation

We estimate stories on an exponential scaleusing the Fibonacci sequence, 1, 2, 3, 45, or 8 points. These units do not correspond directly to developer-hours.

• 1 Point: Trivial. Typically a change in configuration only. Example: Sorting a list by a new field when the logic for sorting is already in place.
• 2 Points: Easy. Changes are straightforward and do not involve complex logic or new components. Example: Allowing the user to delete resources already displayed in a list.
• 4 5 Points: Normal. Changes may involve complex logic, a new component, or cross-cutting changes to the codebase. This is the ideal granularity for stories. Example: Creating a new page which presents a list of resources (including appropriate links to that page, and tests for those links and the contents of the page).
• 8 Points: Hard. Changes involve very difficult logic, extensive testing, or sweeping changes to the codebase. Implementation details may be highly uncertain and risky. Cannot reasonably be broken up into smaller stories. Use this estimation sparingly (only 2% of our v1 stories fell into this category). Example: Drawing ECHO spherical polygons on a Leaflet map.

...

Our estimation may differ from typical agile projects in the following ways:

We only assign points to stories. Epics are merely an aggregation of stories. Tasks provide no user-visible value. Bugs and improvements are necessary changes that should have been done as part of the original story. Assigning points to bugs or improvements is essentially double-dipping and ruins velocity metrics.

To see this, imagine a backlog with 100 points worth of stories. Let's say we're assigning points to bugs and have an average of 1 point of bugs for every 2 points of stories. Our velocity is 15 points per sprint. We look at the backlog and think we'll be done in about (100 / 15) = 7 sprints. That's wrong, though. 5 points of our velocity is due to fixing bugs, and the backlog doesn't contain bugs. We are assuming that we will write bug-free code for the next 7 sprints, despite evidence to the contrary.

Now assume we don't assign points to bugs. Our velocity is lower, only 10, because we're spending time fixing bugs we've introduced. It also reflects our defect rate. We are finishing 10 story points in a sprint and however many bugs we've introduced. We look at our backlog and say we'll be done in about (100 / 10) = 10 sprints, because our velocity accurately reflects the time spent fixing bugs we're introducing along the way.

Bugs are tackled immediately. In order for the above justifications to work, we Bugs are tackled immediately. We cannot have a huge backlog of bugs. If we've marked something done and it is defective, we fix it. Quality is non-negotiable.

We do not re-estimate stories. The justification for this is similar to the reasons above. Re Re-estimating stories changes the inputs to the backlog and throws off the numbers. Consistency is far more important than accuracy. Velocity will sort it all out.

...