If you are working with Scrum you will have also a sprint planning. Hopefully 🙂
I’m writing this article, because our planning was not so effective and dynamic as i imagined it.
So i want to tell you which modifications we made, to improve it.
Of course, it is still not perfect, but better than before. Maybe you can also use some of the improvements.
Sprint Planning to improve
Before our changes, our planning was very static and took a lot of time to finish it.
This was our workflow:
1. The Product Owner described the upcoming Stories. What he is expecting and the acceptance criteria.
2. Then the whole team discussed about the first Story, and tried as a whole team to break down the tasks.
Estimated each task with hours. Then took the next Story until we reached our maximum hour for that sprint.
3. Then the team committed the Stories they could do in that sprint.
We changed our estimation from hours to each task, to hours for the whole Story. So we did not had the discussion on each task.
We moved it one level up. Through this we saved time.
We changed the estimation from hours of each Story to man-days.
This is quite not a big improvement but it changed the mindset a little bit. Its easier to estimate for us.
We introduced the Acceptance Testing with Specflow. So, the PO is writing now the Acceptance Tests with Specflow.
So he can now explain the Acceptance Criteria with these prosa written tests.
In each sprint, a group of Test developer writes the tests and the developers writes the code with TDD.
So we could split the development of the Unit tests and the Acceptance Tests.
This was the biggest improvement we did so far. Before the whole team broke down the task for the Story.
Now we decide after the intro from the PO which Story will probably be done from which guys.
So we split the two teams into smaller group of 2-4 people and breaking down the Stories.
Often we have about 2-4 feature groups and each group has approximately 20 minutes for each Story. So, ideally, we can create tasks for 12 Stories in one hour.
Before that improvement we estimated about 2-3 Stories in one hour. This is really a big improvement.
And also, we do not have to estimate the needed hours for each Story in the whole team, just in the feature teams.
Except there are some additional questions, we doing the estimation in the whole team. Because, more number makes an better estimation.
We will introduce a pre-planning meeting, to work for the future. So we can estimate Stories which will come in next or over next sprint.
So we are prepared and know what is coming in the next sprints and can do ATTD (Acceptance Test Driven Development).
So in sprint one, we are writing the Acceptance Tests for Sprint to.
That’s much better, because the developers know what is expected and can write code against these Acceptance Test.
So, that’s for now. If you have some additions, please let me know how you are doing it, we all can learn from each other 🙂