Skip Angel: The Case for Story Point Estimates

Here's an older post from Skip Angel that's great: The Case for Story Point Estimates

I have been a fan of story points ever since I attended a seminar several years
ago where Mike Cohn presented the concept. I never really trusted other
estimating practices such as function points and time-based estimates. Why?
Software development projects are rarely similar from project to project, yet
these practices focused entirely on past experience. Therefore, to get a
"reliable" estimate of time for every new project you needed to gain a lot of
experience. In other words, you have to figure out up-front how you will do the
work. Not only does this take a lot of investment up front, it also does not
account that the work you do later could change based on the work you do now.
The estimates assume that nothing will change in the effort of doing the work,
which is definitely not true in the Agile world. What I like about Story points
is the focus is on the relative size of "things", then how they will be
accomplished. As Mike would say, "Estimate size now, derive duration later".

Read more here: http://leanagile.blogspot.com/2007/05/case-for-story-point-estimates.html

Good stuff, be sure to check out the rest of Skip Angel's posts while you're at it!

Project Management: Making a Waterfall Project Succeed

Exploring Solution Spaces has an interesting post Making a Waterfall Project Succeed. Here's an excerpt:

Many moths ago, I read an informative and often amusing book called It
Sounded Good When We Started: A Project Manager's Guide to Working with People on Projects by Roy O'Bryan and Dwayne Phillips about (among other things) a waterfall hardware/software project whose management got disconnected from reality and the author had to take over project management to get the project back on track. Many of the techniques he used (putting the project plan on the wall as a frequently-updated information radiator, low-overhead daily updating of current and near-future planned tasks, avoiding delays between engineering activities andquality assurance activities) are also used in Agile projects.

Read more here: http://homepage.mac.com/keithray/blog/2008/01/27/

Great Quotes on The Majesty Of the Mystical Man-Month

Brad Appleton has an excellent post highlighting the continued greatness of "The Mythical man-month" and the lasting legacy of the book and m3Rule: The Majesty Of the Mystical-Man-Month. In it he provides a ton of links to online resources on all things MMM - articles, definitions, course lectures and, my favorite, classic quotes from/on The Mythical man-month book and concept:

“Adding manpower to a late software project makes it later.”

“How does a project get to be a year late?... One day at a time.”

“Nine women cannot deliver a baby in one month”

“Plan to throw one away; you will, anyhow.”

"The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 percent) chance of introducing another. So the whole process is two steps forward and one step back."

"First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well."

"Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.

For more resources (a TON of links) on the Mythical Man-Month, please refer to Brad's original post: http://bradapp.blogspot.com/2008/01/majesty-of-mythical-man-month.html

Technorati tags: Project Management, Mythical Man-Month, Mystical Man-Month Rule, Frederick P. Brooks, Project Management Blog

When is a Scrum Master (or a PM) Not?

Excerpt from When is a Scrum Master (or a PM) Not?:

Here are some examples of the problems these nice folks have had:

“When I want to use timeboxes to focus the attention of the project team on the
project, my boss won’t let me.” — a Project Manager

“Our Product Owner can’t
decide on a backlog before the sprint starts. How can we possibly commit to
anything?” — a Scrum Master

“Our Product Owner thinks that reviewing the backlog and have a demo and retrospective every 4 weeks is too frequent, so our sprints are now 8 weeks.” — technical lead working as a Scrum Master

Read more here:http://jrothman.com/blog/mpd/2008/01/when-is-a-scrum-master-or-a-pm-not.html

From the great project management focused blog: Managing Product Development

Technorati tags: Project Management, Agile, Project Management Blog

Welcome to PM Insights

A new project management blog to discuss various aspects of project management, communication, business strategies, leadership traits, technology, and a whole lot more. We plan to share great content from all over the globe and highlight key project management articles, posts, tools, processes and other resources that are critical to successful project management.

We're just getting started but stay tuned for some great content coming your way!