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
We can explore those questions from different angles, but my simplified definition is: a team is a group of individuals moved by a common goal. Everything is better if, in the meantime we move together towards the goal, we share a positive energy and attitude in between the group.
(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
A backlog is such an important asset for each Agile Team and even more important for a company who understands the value to demand for high quality content and well organized backlogs. What I would like to share with you today is a set learnings I did since I’m working in Agile.
Retrospective meetings are recurring meetings that usually take place after the sprint review. These are very important moments to make a team think about what can be improved. But sometime there are moments when the team is faced with some difficulties in dealing with problems.
Sometimes when we are requested to present a Product Roadmap 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? MOSCOW can help you 🙂
I already did many Refinement meetings (or grooming meetings, as you prefere it). I think those are my favorite AGILE ceremonies, that moment where after a delicious, creative and smart discussion everybody selects THE CARD!!! There you observe so many things: who leads, who knows, who loves risk, who is more cautious, who influences, who will implement it 🙂
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?