Thursday, April 28, 2011

How to Calculate Story Points

Story points are an arbitrary measure of how difficult each phase of a story will be to implement. They are used by scrum teams to represent the effort and complexity of a project, rather than the hours that actually go into completing tasks and objectives—a model that's useful when team size, productivity, and other external factors can't be predicted.

Because every team works at a different rate, you might not be able to predict the exact time frame of any given story—but representing the effort as story points can provide a constructive framework for future planning and implementation. All of this depends, though, on accurately predicting story points.

As a rule, the most effective story point calculation comes from the collaboration of your entire team. As you discuss story points, start with a list of tasks that can be divided into stories. Select the simplest of these tasks and set the story points for this task at 2. The points value of other tasks will be calculated relative to this value.

From there, you'll tackle the other stories individually, allowing each team member to vote on a story points value, then discussing the votes in order to understand why certain tasks are more or less complex than others. For a truly effective story points model, you’ll need to take each team member's input under consideration and reach a consensus on each task before moving on to the next. Through this process, you'll create a system that makes it easier to estimate the time frame for a variety of tasks and to assign fair, motivating targets for your team.

Agile vs. Waterfall

It's a topic that’s endlessly debated at project management meetings and trainings, yet there is still no general consensus over whether Agile or Waterfall is the more robust model—and there probably never will be! Each PM methodology has its own strengths and weaknesses that make it appropriate for certain teams and situations. The following is a very brief summary of the differences, benefits, and drawbacks of each.

Understanding the Basics

As the older and more traditional model for software development, Waterfall depends on the early development of a logical plan that works in a very linear manner. In fact, each stage of a Waterfall project may have a different team and its own unique objectives, moving forward toward completion in an organized model with a planned timeline and goals.

In contrast, Agile was developed to circumvent Waterfall's biggest problem: the inability to make changes to a project's plan without essentially going back to the drawing board and starting over. Agile is open to later input and adapts easily to changes. It's also known for presenting a much lower starting overhead and more leniency in absorbing mistakes.

Predictability vs. Flexibility

While Waterfall makes it possible to predict, plan, and schedule project steps in advance, Agile offers flexibility and adaptability. Agile is superior at handling the inevitable bumps in the road that most projects experience, but it's not as effective at predicting in concrete terms the course a development project may take, the timeline, or even the eventual outcome.

Changes and Collaboration

In Waterfall, it's very difficult to go back and make changes to existing code without redesigning the entire system from scratch. That's because each stage is planned in advance to flow naturally from the one before it, sometimes with a new team assembled for each stage.

When using Agile, on the other hand, it's much easier to involve customers in your project as it develops—in fact, customer collaboration is one of the Agile watchwords—and to improve on previous work over the course of a software development project.

Agile or Waterfall: Which Methodology is Best?

The answer will depend mainly on the scope and goals of your project, as well as the technology you're using and your client's guidelines and approach to feedback.

There's no definitive argument that one approach is better than the other—but there are certainly better choices for individual projects and programs, depending on whether your customer has a concrete goal and timeline at the start or will want to provide input during the course of software development.

Sunday, January 16, 2011

Q: How can I start my project kickoff meeting off on the right foot?

What's so important about the project kickoff? It might seem like just another planning meeting to your staff, but it holds a distinct significance. The kickoff meeting is the first time your client will see your entire team in action, so it's important to project complete professionalism and competence to earn their confidence.

First and foremost, make sure to work with the account manager who closed the deal - they know exactly what the client has already seen, and which information has yet to be presented. You'll also want to review all of the account documentation and ensure that you have a budget and target schedule ready for the meeting. Prepare in advance and make sure your team is primed and ready to make a great impression.

It's wise to speak briefly with the customer before the big day to introduce yourself, establish topics of discussion, and ensure that you understand their expectations.
Follow these steps and you're sure to knock your next project kickoff out of the park.

Monday, January 3, 2011

Welcome to the Tampa Bay Project Management Blog!

Tampa Bay Project Management focuses on the delivery of exceptional project management solutions and staff in the Tampa Bay, Florida area.  Whether it be project recovery, governance, installation of agile, waterfall or RUP methodologies or staff augmentation, we can assist in solving your project management needs.  This blog will host a number of project management discussions, best practices and more.

Michael Achilles | Director, Project Delivery Practice

Tampa Bay Project Management, Llc
3111 W. Dr MLK Blvd, Suite 100
Tampa, FL 33607-6232
T: 813.375.9525
Yahoo/Live/GTalk/Aol: TampaBayPM