Skip to main content

Story Kick-offs Vs Iteration Planning Meetings

In one of my recent projects we tried a new technique of brainstorming a story which we called 'Story Kick-offs'. Story Kick-offs were mainly about discussing the stories to be played within an iteration in more detail. All members of the team; Devs, Testers, UX, PM, IM, BAs would participate in this meeting. Typically, the BA responsible for a story would walk the team through the details of the story and then questions from the team would be addressed. Depending on the team size and number of parallel streams that could be in play, typically, 2 or 3 stories would be discussed during this meeting. We would have atleast 3-4 Story Kick-off meetings per iteration to cover-up all stories within the iteration. The Testers would already have some knowledge of the stories being discussed, since they would have reviewed the stories before they were sent for customer sign-off and ideally have already written test scenarios for the stories to be discussed. After our first story kick-off meeting, we saw a major difference in the way the story was delivered. Here are some observations which i am listing below
  • Since all team members were part of this exercise, everyone had context of the story in play. There were multiple people within the team who could answer questions around the story.
  • Even the lamest of questions were answered and nothing was left in doubt during the story kick-off meeting
  • Devs were able to provide a better estimate after having spent some time breaking the story into tasks, given they have a better understanding of what needs to be developed
  • The testers test scenarios would be discussed too, in-order to cover any unambiguous or hidden scenarios
  • The Usability experts would have inputs on certain usability aspects too which would lead to further discussions
  • IMs, PMs too get a good understanding of the story in play, so that it adds to their understanding of the application from a big picture.
This, compared to IPMs were much more beneficial to us as a team. During IPMs, it is difficult to go into too much detail for a story, assuming that there would be quite a few stories to be covered in a given amount of time.

Having said this, IPMs were indeed done with the Clients in-order for them to understand what all will be delivered in an iteration and also what were the showcase scenarios that would be done during the Iteration showcase.

It is possible that the style of IPMs done in my organization is different from what other organizations do, so i wouldn't completely discount them off here. Story Kick-offs have worked really well for us and hence we decided to go this way.

    Comments

    Post a Comment

    Popular posts from this blog

    How does one decide what to automate?

    A question that has been troubling me for years is how much to automate. We all like to achieve maximum coverage and build a robust safety net where possible in order to give us confidence about the system under test. Given there is ample time i would like to automate almost everything, but in the real world, this isn't possible. This is when we introduced the concept of Value and Cost for a test scenario. Every test scenario would be assigned either of these attributes. Lets call the attribute automation classification High Value - Low Cost High Value - High Cost Low Value - Low Cost Low Value - High Cost What this translates into is we are associating business value and cost to automate to every scenario. So, when a test scenario is of high business value and the cost to automate it is low, then this becomes our ideal automation candidate. You would like to start automating all test scenarios that fit into the High Value - Low Cost category first. See picture below If tim...
    1 comment
    Read more

    Test your services and not your UI

    As a tester, i have spent more than 6 years trying to automate tests at the UI layer. As years passed, better automation frameworks evolved resulting in writing more manageable and maintainable code, but the only thing that wasn't getting better was the cost of maintaining these tests, especially when the no. of tests were 500+. There are multiple reasons why i feel creating an automated regression suite of tests at the UI layer is not good. Some of them are Limitations on what the tool can do Time taken to execute these tests leading to longer feedback loop Success rate of tests is not 100% due to latency issues Change in UI and UI flow resulting in an increase in cost to maintain UI tests On the other hand, testing business logic without having to deal with the dumb UI was a concept that a friend of mine at ThoughtWorks, Chirag Doshi introduced to me. He sent me couple of blog links written by Alex Verkhovsky about why is it so hard to do functional test automation at th...
    1 comment
    Read more

    BDD is over-rated

    Over the past few years, I have tried to justify the use of a BDD (Behavioral Driven Development)  framework to express my tests, but not once have been able to say BDD has helped me address a  problem which writing tests the non BDD way would not have addressed. I do understand the value BDD brings to the table, but in most projects that I have implemented BDD on, we have tried to provide a solution (BDD) to a problem that does not exist. Let me try and explain. Lets look at the key benefits of expressing tests the BDD way (There could be more) Collaboration between Business and Development Ubiquitous Domain Language Focus on the behavior of the application Now, more often than not unless your business is co-located with the team, collaboration is not the easiest. The value BDD brings here, is the business validating our understanding by reading our tests expressed in the Given When Then format (BDD) and providing feedback, as BDD expresses the behavior of the syst...
    1 comment
    Read more