



If the story is not in a good shape, then we have a higher chance of a story going back to analysis and not actually getting started working on after a story kick-off. Also, when we pick up a story for story kick-off we expect it to be in good shape already and story refinement provides that. If story refinement sessions take place in your team, story kick-offs act as quick refreshers that go super smooth. They both can happen and have different benefits. Story kick-offs and story refinement sessions are not mutually exclusive. You may be doing story refinement or grooming sessions where all the team already takes a look at the stories, provides feedback, and collects/answers open questions. What about story refinements? Isn’t that the same thing? It was all a big misunderstanding that could have been avoided if we had walked through the story before it was implemented to make sure the expectations will be met. What the business analyst and product owner actually wanted was to log in with their own accounts using the auth service of the organization. After finished development, we realized that for developers who created this feature “user” meant any user, so they created their own auth service and assigned an admin user. Acceptance criteria stated, “User logs in and sees this”. In the past, I’ve seen teams skip the story kick-offs and then get the work moved back because of misunderstood requirements.įor example, once a team was working on a tool that involved a login. Developers may ask BA to clarify what was meant with acceptance criteria or talk through how the testing will be approached with the QA. If we are working with a mindset of building quality in and want to seed natural collaboration in the team, we need to make sure all roles are involved early on, and that we have as little misunderstandings as possible. In this usually 10-20 minutes meeting the group takes a look at the acceptance criteria, clarifies any unknowns if there are any, and makes sure to confirm that everyone is on the same page. The goal of a story kick-off is to have a final alignment on what is going to be implemented. I have seen other developers attend these meetings, too, just to be on the same page in case rotation happens or if they’re interested in how the story will be tackled. Story kick-off is an agile ceremony in which developers who are about to start working on a user story (or another work item) discuss the story together with other roles from a team like business analyst (BA), quality analyst (QA), experience designer (XD), or even the product owner (PO). This helps us avoid rework and build higher quality products before it’s too late. This is why I really like story kick-offs: they’re a chance for us to verify if our assumptions are actually true or not.
KICKOFF VS KICK OFF SOFTWARE
Way too often in software development the main problem is unvalidated assumptions. I fully agree with this description because agile is all about collaboration and people. The one thing clear is that story kick-off is very often considered to be an agile ceremony. There’s no one name or organization that I could assign as pioneers. Trying to find more information on it, I realized that even if there are some articles on it, the origin of a story kick-off is not as obvious. Story kick-off is such a natural ceremony/ritual to me that I tend to forget how uncommon it may be outside my organization.
