project planning
|
Using Product Economics for Feature PrioritizationWhen planning for feature prioritization, it’s crucial for you to take into account product economics. Sameh Zeid writes that product economics helps us to understand if it is financially viable to develop a product, even more so than relying on business value. | 
|
|
Self-Organizing Teams and New York's Soda Size BanVenkatesh Krishnamurthy relates New York's unpopular soda size ban with the conflicts that arise from self-organizing teams. Michael Bloomberg (ScrumMaster) had good intentions to save lives by bringing this change; however, he didn’t get support from the citizens (self-organized team). | 
|
|
What Is a True Agile Coach?Obtaining a Scrum or agile certification typically does not require that a person learn the fundamental differences between coaching, facilitation, and mentoring. This lack of understanding is reducing the quality of coaching to our customers. |
|
|
Why Do IT Professionals Succumb to Project Overload?Joe Townsend explores why IT professionals continue to succumb to project overload. The problem is not that we take on too much; the problem lies in the fact that we don’t manage our projects very well, and these repeated failures lead to overload as we can’t deliver what we promise. | 
|
|
The Difference between Outcome and Output in Product DevelopmentTo be successful in product development, we must minimize the number of product features while also delivering what the customer will like. In other words, product development success is governed by our ability to maximize the “outcome” rather than “output” of product development. |
|
|
Signs of a Doomed ProjectNaomi Karten shares some common signs of a doomed project. The early signs of a project in trouble include a lack of interest, chronically poor communications, a no-bad-news environment, and people attending meetings but not paying attention. | 
|
|
Why Retrospectives Are Important in Agile Software Development Periodically reviewing how things went—and looking for ways to improve—is an essential part of agile software development. Retrospectives are one way to do this, but it’s important to understand that there is a difference between a structured retrospective and “just talking about what happened.” |
|
|
Take the High Road When Creating Product RoadmapsOne of the mistakes made when crafting a product roadmap is building a roadmap that schedules all the features and functions you plan to build. That’s taking the low road. You want conversations with customers to be focused on the problems people solve with your product. That's taking the high road. | 
|