Slides: http://www.slideshare.net/voximate/introduction-to-agile-project-management-and-scrum

Introduction to Agile Product Management and Scrum

Presenter: Eric Krock, Voximate

Notes thanks to David Barkovic (with minor clarifications of intent by Eric)

Issues with waterfall include finding out too late that you’re too late.

PRDs get you sucked in your “self-assumed brilliance about what the market needs.”

Must understand the goal of the user as part of the user story.

As a (user), I must/want/wish to. This is equivalent to the ubiquitous P1, P2, P3 prioritization labels.

Story points are an abstract measure of *relative* effort. Story A is about 3x the effort than that of story B.

Fine grained prioritization mechanisms (ex. On a scale of 1-100…) can imply false precision. Many folks use the Fibonacci sequence to help avoid that.

You do actual time estimates when you create tasks.

No partial credit. You get the points only when the story is complete.

There’s a bit of a debate in the Agile community on whether defects should be tracked with points. There’s also the more general problem of non-story work.

Even if you don’t track issues using points, the velocity will eventually take into account the average number of distractions since they reduce the velocity. On the other hand, tracking issues via points will give you insight into the amount of resources required for the work on issues rather than new feature development.

Eric recommends Mike Cohn’s book – User Stories Applied. Same goes for Mike’s other books.

You’re always doing something for someone. The stories need to be clear on who that is. This includes both internal and external stakeholders. “As an engineer, need to refactor the codebase in order to…”

At the end of each sprint, you must return the product to a working state. That’s how you know you got the work done. Avoids the hidden step backwards when you’re trying to move forward.

Scrum managers are typically the engineering managers.

Difficulty with keeping the daily stand-up meeting to 15 minutes. Take problem discussions offline and keep the discussion to what each person is working on.

Product owner always participates in the daily scrum. This is much easier provided you can keep the meeting short.

Need test driven development – automated tests. If you’re doing manual testing, you wont be able to do get the product back to a reliable state after a one week or two week sprint.

Don’t really know the requirements of the foundational work until you develop the features. All the work should culminate in a feature of the product. This is depth first development, rather than breadth first development typically seen with waterfall projects.

The user story is the basis of a conversation on the actual development. It is not the spec. The goal of the user story is to get engineering to talk with product management.

Engineers update sprint burn-down charts every day.

Wireframes should be managed as a task derived from a user story. With that said, a wireframe could span multiple stories.

Two week sprints may be a good sweetspot for most organizations. One week sprints are typically better for small teams.

Do a three to five week moving average to get your velocity for the release.

Ideally, Product Owners should not be doing even tentative assignments of user stories to sprints more than three sprints out. Any more than that may lead to wasted effort as priorities change.

Eric recommends not having a single backlog. Should split the high-level stories or epics into multiple categories such as current release, next release, future. This avoids cluttering your collection of near-term stories with things you’re not going to touch for a really long time.

“Nothing is impossible. It’s just difficult and painful.”