Sprint 4 - Long running Sprint Planning meetings

Since two sprints, we are noticing that the sprint planning meetings are going over 4 to 5 hours! Sometimes, we can't get a conference room, and we are forced to split it into two sessions.

After analyzing the reasons for these long meetings, we realized that our stories were complex and most of the time was spent in discussing requirements in the sprint planning meeting. Many times product owners ended up changing stories after discussing them with the engineers. Product Owners learn about technical dependencies over other stories or they choose to break up a story in a different way after discussions with engineers. Engineers even point out inconsistencies in the stories e.g. xyz tab lists contacts in ascending order, why is the order different on this tab? Most importantly, many times engineers pointed out the missing pieces in the stories.

This dialog between product owners and engineers needs to happen on consistent basis rather than just in a sprint planning meeting. Product owners should consult with experienced team members after writing a story. They can forward the newly written story to an experienced team member and ask for his/her feedback. They can ask the engineers to estimate points for the stories so that they can decide whether to break the story or not.

The team should help product owners to evolve stories. We have constituted a weekly hour long meeting for playing planning poker. Planning poker forces the much needed discussion about future stories between the product owner and the team. But these planning pokers are not sufficient as the focus of the meeting is just to know enough about story so that it can be scored. They should be supported by informal hallway discussions and mailing list questions.

Incremental, Agile QA

Incremental QA is highly desirable in Scrum. Scrum does not distinguish between development and QA as in waterfall model. It expects that the product feature you are working on is designed, developed and tested by the end of a sprint - One sprint does it all.

Here are some important characteristics of incremental QA:

1. QA developers are part of the team. Scrum does not distinguish between QA developers and other kinds of developers. They all are part of the same team and are equally responsible for the success of the sprint. The team is cross functional.


2. Builds are given to QA more frequently. Daily builds are recommended. We have even delivered builds twice or thrice a day depending on the issues QA has found. If the issue is simple to fix, fix it and deliver the build immediately. Your build process must be capable of delivering a build to QA in a short time.
   


3. QA develop automated tests while developers are coding user stories. These automated tests will be used in the current sprint as well as in future sprints for regression tests. Tools like Selenium and Fitnesse are used to achieve high degree of automation.


4. Close coordination is required between developers, release engineers and QA. As new features are completed, the changes must be pushed to QA environments as soon as possible so that QA can begin. This means you need to have an efficient process to create QA environments. As soon as a bug is detected, it should be communicated to developers and developers should deliver the fix as soon as possible.


5. Sometimes, partial testing is done. A developer may not be able to complete an entire story at once. He/she may deliver whatever has been completed to QA - may be 70% of the requirements. The developer communicates this to QA and expects QA to test only the portion completed.


6. Developers take up testing tasks, if necessary. They can test their peer's code if there aren't enough QA engineers available to accomplish the testing required for the sprint.

If your team is getting QA done in a way described above, you may pat your back as you have achieved the holy grail of incremental, efficient and agile QA.