Why should we estimate? What are we considering when we do it? Yes, estimation accuracy is a matter of practice maintaining the same team constant. What and how can we estimate? We can do it all over hierarchy of requirements, since strategic levels until implementation ones. But essentially a good product planning should be done to slicing features maintaining product value and introducing complexity across the product development phases.Continue reading “Why should we estimate?”
It’s always annoying when something comes up out of the plan and the team must fix it or manage it inside the sprint. Unfortunately, we must deal with unpredictability. Nevertheless, is always good to analyze why we had to deal with those annoyances.
What can be considered an annoyance? In my opinion, we can consider as critical bugs or unplanned change requests, we receive during the sprint or release and we must integrate or fix it within the sprint. In this post, we will approach, in a generic way some reasons for this and if it happens, who will report it into the backlog and which other measures should we consider to keep the sprint in a normal speed.
Continue reading “Annoyances: How to deal with critical issues, not planned, entering in the middle of the sprint or release”
The Product Owner role for a software product in an industry where the core business is not IT is a business enabler, a business transformation agent and an innovation partner. Someone who his success depends on the success of the business he supports. Sometimes it reminds me a marriage, an alliance.
In this post I would like to share my thoughts about the required skill set we should look for, when hiring one. Continue reading “If you are out of software industries and you are planning to hire and IT Product Owner, you must read this post!”
(Berlin, Memorial to the Murdered Jews of Europe) – Some weeks ago, when I visited the Memorial, the feeling of loneliness and lack of direction invaded me. I think this is the main achievement of the architect (Peter Eisenman)… bring this feeling to the visitors. And from the position in the picture I asked to myself “What have we learned from this horror?”. Inspired by a continuous learning for a continuous improvement, I would like to make the question applied to bugs and change requirements (CR), but particularly in this post: what can we learn from bugs? We should take them all as improvement opportunities.
In my last post I didn’t have room to explore other backlog issues, which become more important once it starts the implementation phase: bugs (or defects) and change requirements (or change requests – CR). Bugs must be included in the backlog, they will take capacity to be solved and they bring user dissatisfaction. In this post we will touch different questions: which type of bugs and CRs we can face, in which contexts we will face them, who normally will report them into the backlog and the product owner dilemma between occupy capacity with new feature or fixing bugs or improving/ adapting product details (CR).
Continue reading “Bugs, change requirements and the PO dilemma”
A backlog is a very important asset for an Agile Team. It becomes even more important for a company who understands its value and is able to demand for high quality content and well organized backlogs.
Let’s try to understand what is a Backlog and all value behind this organized list of work by epics and stories shaping the product strategy.
A release plan is an extremely important negotiation process. It should be factual, considering dependencies, anticipating risks and sharing with your Product Owner concerns, plans to improve the product in non functional requirements (e.g. QA, Security, Performance, etc.). You are managing expectations, challenging how reliable is the predictability of your Dev team. But should you only consider your MPP? How can you avoid emotions in the release planning process?
Continue reading “Get ready for a Release plan negotiation!”
(Antwerp, Belgium) I write to you from the city where the concept of logistics was reinvented over time, to talk about the management of systems portfolio and software requirements and how the most traditional methods are not consistent with the current reality.
Continue reading “The reason why the applications and systems portfolio management methods do not fit more into the current business reality”
Sometimes when we are requested to present a Product Road-map it is hard to start… Start from where? Which features? Which inter-dependencies? How to define priorities? Priorities in the order of the tasks or in the features to enhance product value?