To me, the sprint review is an extremely valuable ceremony. The principles behind the session itself are powerful, universally true, and can be applied outside of Scrum as well. Nevertheless, I feel that the goal and the importance of the review is sometimes misunderstood.
In agile product development, particularly in Scrum, it is common to estimate user stories. Most of the time, an estimation of a user story is done with story points along a fibonacci series. User story estimation is a valuable but inherently subjective and inexact process. I also believe it is often misunderstood.
I have realized that the distinction between different types of value created in product development is very important. For long term success the value to end users needs to be (back) in the center.
Whenever I start working with a new team, one of the first things we do is defining the Definition of Ready as well as the Definition of Done. Defining and using those two artifacts is not overly complicated but saves all involved from a lot of stress down the road.
Nevertheless, I frequently find teams that use neither or don't even know what they are. Thus, I think it makes sense to address what Definition of Done (DOD) and Definition of Ready (DOR) are and why they exist.
Don´t get me wrong, many software tools are fantastic products. I use a wide variety daily. However, I feel like their impact is overvalued. Or maybe, to put it better, I think they are misused. Far too often is some new license for a tool purchased because “we are not meeting our targets”. The hope is then that the tool magically solves everything. Spoiler alert: It doesn't.
Can Scrum and a Scrum team work without a Scrum Master? The short answer is yes. I believe it is possible. The longer answer is a bit more complicated. The Scrum Master Role was created for good reason and not having one will lead to some negative effects.
It generally seems to be the case that we have too many ideas for improvements but not enough time to do them all right away. Therefore, backlogs tend to become large. In order to be able to handle this, it is so important to organize the backlog in a structured way.
Writing a user story is not rocket science. Nevertheless, it is a point of significant leverage for the success of product development. As such, I feel that the task is undervalued. Thus, this post describes how to write user stories.
The Product Owner (PO) is an extremely important role that includes a diverse set of responsibilities and an empowered PO can have a tremendous impact on product development, if he or she is able to handle the many jobs of a PO. This raises the question of what skills are needed to do just that. Thus, in this third installment of the series on the PO I will focus on answering the question What are the core competencies of a Product Owner?
In general, it seems most people agree that remote work is a net positive but it also poses some challenges. Very underrated are the effects of remote work on company culture. The challenges to building a real team are probably more obvious. Nevertheless, I feel they are worth addressing.