Why should we estimate?

https://onceyougoagile.wpcomstaging.com/why-should-we-estimate/

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?”

If you are out of software industries and you are planning to hire and IT Product Owner, you must read this post!

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!”

Bugs, change requirements and the PO dilemma

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”

Requirements hierarchy, what should be written per level and by whom

(Berlin, Germany) Sometimes the most obvious Agile concepts are not so easy to be applied when we need to make a practical usage of them. Specially if we need to bring into a consistent and common understanding a product or portfolio vision for later implementation. My goal with this post is to share a very personal opinion about how and whom should fulfill those Agile requirements levels.
Continue reading “Requirements hierarchy, what should be written per level and by whom”