Once you have done your User Story Meeting, Planning Poker and Collaborative Release Planning, it’s time to get to work. Your Team Members can simply start working on the User Stories due for the first Iteration. After all, most people who work in projects, are quite used to be let alone and to just do their work. The fine-tuning of your Lean and Agile Project Management starts at the first Iteration Meeting.
Iteration meeting, 1st half: Looking back
Let’s assume that you have your first Iteration Meeting after the project has started. In that case, you’ll have worked on a couple of User Stories and preferably even completed them. The first goal of the meeting is to share the results among all team members, stakeholders and possibly the client too -and to tick off things from your list-. So, you run through the list and simply say DONE or NOT DONE. If’ User Stories are not done, it’s a good idea to find out why. Was it too much work? Has an external supplier been missing? Have team members been doing other things instead? Was it unclear what exactly needed doing?
Whatever the reason, it helps to clarify it -and to decide on a way to handle it next time.
Right sizing User Stories
If a Story proved too much work to be done in only one Iteration, the Team may want to learn to slice up some of the Stories next time. Generally, it takes a couple of Iterations for a team to learn the exact scope of User Stories. As a rule, you’ll want to have User Stories which may be completed in one single Iteration, which are independent (that is, they don’t need to wait for other stories to be completed first) and which contain individual tasks for different individual team members.
If an external supplier has been missing it may be a good idea to inform him or her next time, or even to invite him or her to the next Iteration Meetings. It’s very valuable to work with integrated teams, including all suppliers and clients: With all who have things to do during the Iterations at hand. That way, they continuously have a shared vision on the project details and all understand the importance of delivering on time. If it’s not possible to do it that way, second best is to include some tasks for someone to keep suppliers posted.
If Team Members have been doing other things instead it may be a good idea to now introduce a Planning Board on one of the walls. A Planning Board helps to keep the Story Cards in sight of the entire team. And it’s a great place to do Daily Standup Meetings and to daily discuss what to do and what not. Simple and straightforward Planning Boards contain a column for the ‘Backlog’ of User Stories and Tasks during the Iteration, a column ‘In Progress’, where we pin the cards which Team Members have actually picked up (so not the Tasks which they only intend to pick up), and a column ‘Done’. During the Iteration the User Stories and Tasks should be moving visibly from Backlog to Done. Some Planning Boards include another column for ‘Testing’ or ‘Quality Assurance’. If so, this column is best placed to the left of the ‘Done’ column. After all, when a User Story has been completed or done, nothing more needs to be done to it.
Finally, if it’s been unclear what exactly needed doing, it’s a good idea to introduce the process of breaking down User Stories into Tasks. A User Story is a result with Tasks for different Team Members. Defining Tasks, you’ll get to the detail level of exactly what needs doing by whom, and also, how much work this actually would be. It usually helps to do such a breakdown exercise and to get quite specific on what to do. This way, your team will get a better understanding of how it does things. It forces the specialists to be specific on what it actually is what they’re doing. It helps to have other team members picking up these pieces of work too. And or to provide instruction to team members on specific tasks.
Of course, there may also be other causes for not completing all User Stories. Then you’ll do the same: Ask why and fix it.
Iteration meeting, 2nd half: Looking forward
The second half of your Iteration Meeting is on the Iteration to come. Time for some more tools to be introduced: Team Velocity, Setting Priorities, Tasks and Continuous Improvement.
If you have done Planning Poker prior to this Iteration, you theoretically now know what velocity your Team may be expected to reach. The Team Velocity is the amount of User Story point which a Project Team is able to produce during an Iteration. If you’re Team has done 25 User Story Points during the first Iteration and if it has worked on relatively normal conditions, you can expect it to be doing 25 points in the next Iterations too. This fact allows you to review your Release Plan already now. You can calculate when you’ll complete your project, if your Team continues working at 25 points per Iteration.
So, knowing that your Team Velocity is 25 points, then you can also assess if it will be possible to do what you need to do. There are always solutions to think of: Would you be needing more Team Members? Could you do with less hours per Team Member per Iteration? Are there other ways to do the work -easier or more elaborate-? Or would you know of yet other things to do in order to get your planning tuned?
Having evaluated your Team Velocity and having established the amount of User Story Points your Team will be doing during the next Iteration, you can now decide on which User Stories to do next. These may be simply the stories which were already placed in the Iteration during your Collaborative Release Planning, with some of the uncompleted Stories of the previous Iteration. Or they may be some urgent stuff needed for a Presentation or a Board Meeting, or anything else. This actually is one of the greatest virtues of Lean and Agile Project Management: Accepting, even embracing Change. Yes we can do other things, which are more important, but only if the client decides so.
For each of these User Stories, it’s now a good idea to add individual Tasks. Describing the Tasks, is about the first time you’ll get really specific on the work to be done. It lays the foundations for a Standardized Work method later -and to improve even more-.
Probably not all solutions are brought up during the first Iteration Meeting. If they did, you would have too much work to get everything in place at once. It’s perfectly all right to add tools and solutions along the way, step by step. And after having implemented these tools, you’ll probably want to add many more.