For your weekend reading pleasure, an interview and an article.
Burndown Bullied Into Business Analysis
Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline – and we can apply it to any form of project-status. In this article, we will apply it to […]
Agile Prioritization and Tracking
Stealing a couple cool ideas for managing project priorities with something you can touch.
Quick Thoughts on Incremental Project Management
Incremental delivery planning is not an oxymoron. You just plan the soon-to-happen tasks in detail, and keep the distant tasks more vague. Does this make sense? Rolling-Wave Planning Johanna Rothman has posted an article that provides a good introduction to rolling-wave planning. She explains that she manages incremental projects with […]
Iron Triangle Kills in Boston…
… Skyline Unharmed Short-sighted demands on software teams usually don’t kill people. Software development is often described with a construction analogy. The Big Dig construction project was under exactly that kind of pressure. On July 10th, 12 tons of tunnel ceiling collapsed and killed a motorist. On July 20th, Mitt […]
Communicating A Release Schedule With Use Cases
We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases. Background We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use […]
Make Your Meetings 60% More Effective
While effective meetings may not be the key to success, ineffective meetings are inarguably one of the largest time wasters in corporations. Applying these tips before, during, and after meetings will make us much more effective.
Agile’s Biggest Strength is Agile’s Biggest Weakness
Agile works because it is designed to help teams adapt to changes in direction. Agile is designed to minimize the pain of changing requirements. Agile proponents believe the premise that requirements will change and no amount of upfront planning will impact that. They believe that the requirements simply do not exist until after something has been built. Agile processes save a lot of time by not doing big upfront requirements gathering or design work. They also don’t involve big up-front planning. They do small planning work. And they do it again and again, throughout the project. This works because they minimize wasted planning effort.
Where Did You Get That Estimate?
How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.