I had the pleasure of giving two presentations at the Silicon Valley Product Camp 2011 this weekend. I have posted the slides for “Introduction to Agile Project Management and Scrum.” Since we only had fifty minutes including lots of great audience interaction and questions, this is a very brief, high-level introduction to key concepts for someone who is thinking about getting started with Agile Project Management and Scrum. It covers:
- user stories, story points, and the the use of Fibonacci sequence values for story points
- release planning
- sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts
- the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic
- the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work)
- daily standup meeting in which people share what they did yesterday, what they’re doing today, and any blocking issues they’re encountering
- a few key values in Agile
- common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch
- problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers
- a list of books and web sites by Mike Cohn, Kent Beck, and others to learn more
David Barkovic kindly took notes which I have included below. Thanks to the sponsors and organizers for putting together and managing a fantastic, educational, well-attended conference and to the attendees for great, brief, on-topic comments and questions throughout!
Introduction to Agile Product Management
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.”