What can you learn about your agile project from this Gannt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gannt chart? And how much value are you getting from it?
Category Archives: Project Management
Barrier To Agile Development
Why don’t more companies and teams use agile development techniques? We know some teams just aren’t aware of them – although that list is getting shorter every year. The benefits of iterative development over waterfall development are pretty well established. I don’t believe I’ve seen a study that shows that waterfall is more effective. Do people refuse to believe in the data? Or maybe they are unable to believe.
Perpetually Almost Finished Projects
Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it? In some ways, we’ve known about this problem for almost 2500 years But the solutions are still far from widespread.
Prioritization and Value Maximization
We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.
Posted in Business Analysis, Expert systems, Prioritization, Product Management, Project Management, ROI, Requirements, Requirements Models, Use Cases
Tagged managing data, optimization, Prioritization, prioritizing use cases, time boxes, time boxing, timeboxes time-boxes, timeboxing, use cases, value maximization
13 Comments
Juggling The Elements of An Iteration
You expect analysis to happen before design, and both to happen before implementation and testing. But how much should these activities be staggered? When a project is being run with monthly releases, it might seem logical to have each group working on a different release. For example, the test team working on the current release (3), the developers on the next release (4), and architects and analysts working on releases 5 and 6 respectively.
If your team is this staggered, you have a problem. It takes four months for a requirement to be released from the time the analyst has documented it.
Read the rest of the article …
Benefits of Agile Story Decomposition
When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning – from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure – communicating the release schedule internally with your development team.
Posted in Agile, Product Management, Project Management, Requirements, Requirements Models, Software development, Use Cases
Tagged managing data, managing releases, managing software releases, software release schedule, tasks, user stories, user story, user story break down, user story decomposition
2 Comments
Failure To Deliver Is Not An Option
But sometimes, it happens anyway.
The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.
Posted in Communication, Consulting, Product Management, Project Management
Tagged managing data, product management communication, release communication, release planning, release scheduling, releases, scheduling releases, scheduling releases by use case, software product management
Leave a comment
Planning for Effective Meetings
Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail – helping participants be prepared to participate – in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees – business analysts, product managers, and project managers, for example.
Read the rest of the article …
APR: Scope and Vision
To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.
But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now – but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.
These two project management artifacts seem logical to combine into a single article
Posted in Agile, Agile Project: Ratings, Product Management, Project Management, Software development
Tagged agile case study, agile project, agile requirements management, agile software development, managing data, project scope, project vision, scope, scope and vision, vision, vision document
9 Comments
Latest Articles
Comments on all Articles
