Bugs, change requirements and the PO dilemma

The Product Owner dilemma: new features, bugs, or Change requirements?

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).

Get ready for a Release plan negotiation!

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?

Retrospective Meeting – simple Technics helping to moderate the dialogue for co-located teams

Retrospective meetings are recurrent meetings, that normally happen after the Sprint Review. Those are very important moments to make a Team reflection about what can be improved. But sometime, there are moments where the Team faces some difficulties to start addressing issues.

How abstract really are story points?

Refinement meetings (or grooming meetings, as you prefere it) are my favorite AGILE ceremonies. The moment when, after a creative and smart discussion, all team selects ONE CARD, each team member selects individually one card! And then we try to understand discrepancies between values, why one person voted too high, other too low… this is an amazing moment where so much can be observed: who leads, who knows, who loves risk, who is more cautious, who influences, who will implement it 🙂

Do you know your MPP?

MVP – Minimum Viable Product, expresses the product owner wish list of features to give a minimum value to the user.

MPP – Minimum Possible Product, expresses the team capacity within a specific time frame to deliver value for the user.

With those two concepts we observe that we need to find a commitment in between the desirable and the possible product for a release, as an example of specific period of time.

How can we evaluate results from a PoC?

This topic was initially approached in the post How do you define a PoC? , now the focus will turn to the results evaluation: what have we learned with it? Was it worthy the time invested with a critical feature? Have we enough information to start immediately an MVP?