Annoyances: How to deal with critical issues, not planned, entering in the middle of the sprint or release

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”

What can we learn from bugs?

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

Continue reading “What can we learn from bugs?”

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”

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?
Continue reading “Get ready for a Release plan negotiation!”

How do you define a PoC?

Sometime it can be really hard to structure a Proof of Concept. To acknowledge the time for implementation, to define the goals or the learnings we want to reach by the end of the implementation are often difficulties. So a PoC must have a clear,  small and reachable scope within the upon agreed small period of time. This post is all about the logic I follow to support my decisions to structure a PoC.

Continue reading “How do you define a PoC?”

How abstract really are story points?

Refinement meetings (or grooming meetings, as you prefer it) are my favorite AGILE ceremonies. The moment when, after a creative and smart discussion, all team agrees in one estimation, 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 🙂

Continue reading “How abstract really are story points?”

Do you know your MPP?

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.
Continue reading “Do you know your MPP?”