You are currently browsing the tag archive for the ‘velocity’ tag.
Well well well… this is probably the hottest issue to any agile implementation… most certainly the issue causing the most debate, emotions and pure frustration to any agile team!
Can one convince a team or individual to adopt points over hours, or hours over points?
Well, as an Agile coach I made the massive mistake of thinking that one could!
A few years on, I can now say, one can’t, there will always be a counter-argument to any argument you make… teams and individuals have been conditioned throughout the years NOT to think relative, but in hours… that is just the nature of the beast…
I found the best way to deal with this, in training and in coaching, is to divide the teams into two camps, points and hours, give them reading materials and articles, and let them present the case for either story points or hours… they will debate this one for hours, but its worth the time spent!
However, make sure they at least try relative estimation with Story Points, or let at least ONE team do that… once teams grasp the concept of relative estimation over ‘accurate’ hours, then the benefits will show and most teams will make the mindset change, not to say that one don’t get high-performing agile teams using hours… it’s a preference!
This works really well, and it stays true to what an Agile coach is supposed to do… present the issue, ask some provoking questions and provide the environment for the teams to actively and effectively communicate…
All this said, here is a fantastic article covering both Story points and Hours… http://www.infoq.com/news/2009/09/story-points-versus-hours
Note that we will be covering this subject in detail and in a fun way in our course, Agile Bootcamp planned for 7-8 October 2009! For more information, visit http://www.kaizania.co.za/agile/agile_bootcamp_registration.php
The basic idea of Sprint Planning is for the team to negotiate the scope for the sprint with the Product Owner in a limited amount of time (time box).
The Sprint Planning ceremony needs to be organised and facilitated by the Scrum Master, however, the Product Owner needs to produce the agenda (Product Backlog) for the ceremony.
The Product Owner needs functionality to be implemented and to spend development money wisely. The team wants to select a mandate they can fulfil at the end of the sprint.
This is called a Sprint Contract between the Product Owner and the team.
The purpose of Sprint Planning is for the Product Owner and the team to negotiate what should be accomplished during the sprint (Sprint Contract)
—————————————–
Sprint Contract: It is simply an agreement between the Product Owner, who agrees not to change his mandate before the end of the sprint, and the team, who commits to delivering a defined set of functionality by that time.
—————————————–
Meeting Parameters:
Scrum Master facilitates the ceremony; however, the Product Owner brings the agenda.
Before the start of Sprint Planning, the team had to have seen, understood and estimated the stories, otherwise the ceremony will drag on and a productive Sprint Contract which needs to produce a product increment to support the financial investment will not be reached.
It’s important that the stories produced by the Product Owner needs to be small enough to be delivered in one sprint and well defined acceptance criteria ( conditions of satisfaction ) will increase the team’s ability to deliver the planned product increment at the quality level expected by the Product Owner.
It is important for the team to understand their capacity upfront in order to gauge the amount of work they are willing to accept into the Sprint Contract.
That will also enable the team to negotiate buffer stories with the Product Owner as part of the Sprint Contract, however, only to be done if the team has completed ALL the stories to completion as set out in the Sprint Contract. Buffer stories will enable the team to take on more work may they finish the Sprint Contract before the end of the sprint, therefore, increasing the sprint velocity and assisting the Product Owner to produce higher return on investment for the sprint.
It’s important to note that Sprint Planning in total needs to take no longer that one working day. Sprint Planning 1 – Backlog Analysis Workshop (4 hours), and Sprint Planning 2 – Selected Backlog Design and Task break-down (4 hours).
Sprint Planning in practice
Preparation:
The Scrum Master has the following preparation duties:
-
- Prepare the team room/space with all the necessary equipment the team and Product Owner would need to effectively communicate and plan (flip charts, whiteboard, pens, paper, projectors, laptop, sticky notes, printed stories etc)
- Prepare the team capacity and help the team understand their own capacity for the sprint (find out who’s on leave etc beforehand)
- Ensure and assist the Product Owner to produce a well-defined, estimated and prioritised Product Backlog at least a day before Sprint Planning to the team so the team can be well prepared.
- Collate and prepare the output from the previous Sprint Review and Retrospective.
The Product Owner has the following preparation duties:
-
- The Product Owner needs to, with the assistance of the Scrum Master, ensure that the Product Backlog is understood and estimated by the team.
- The Product Owner needs to ensure the team receives the prioritised Product Backlog in-time to be well prepared for the Sprint Planning sessions.
- The Product Owner needs to ensure that all stories within the Product Backlog has well-defined acceptance criteria (conditions of satisfaction) attached to them in order to assist the team in gauging the scope and desired outcome of each backlog item.
The team has the following responsibilities:
-
- Assist the Product Owner in estimating the Product Backlog before the Sprint Planning sessions.
- Prepare themselves on the Product Backlog produced by the Product Owner before the start of the Sprint Planning sessions
Moderation:
Scrum Master kicks off the ceremony by ensuring that
-
- The team understands their capacity for the sprint
- The team understands and have access to the previous sprint’s review and retrospective items
- The team understands and if necessary enhance the Definition of Done (DoD) for the sprint
The Product Owner will then inform the team of the release vision and the planned sprint goal and communicate with the team in finalising the Sprint Goal.
The Product Owner will then present the Product Backlog to the team whereby the team will start to analyse the Product Backlog from the top by…
1. Starting with the first item on the backlog understand the requirements of that backlog item (use your flipcharts)
2. Understand the acceptance criteria (conditions of satisfaction) for that backlog item
3. Once the team has a clear picture of what needs to be achieved to complete that item, they either accept or decline that item into their sprint.
4. Then start again from point 1 until the team feels that they have reached their sprint acceptance saturation point
———————————————————
Note: Ensure that your team does not accept items into the sprint based on the estimates of each item making up the sprint velocity, nothing is more wrong – ensure that your team accept items based on the understanding of what needs to be done and willingness to complete that item within the sprint
———————————————————
It’s important that the Scrum Master facilitates the whole process and ensure that the team are tracking well in the time allotted.
It’s also very important that the Scrum Master does ask the team at some stage a very important question on the items they have already selected from the top. Are they still comfortable with what they selected and that they will be able to deliver to complete satisfaction at the end of the sprint?
At the end of your first Sprint Planning session after the team has selected their items to be included into the sprint, send the Product Owner away and then repeat the question above to the team again, however, this time more serious!
Once the team has answered and made their commitment to deliver the selected items to full completion at the end of the sprint, then communicate the final selected list of items to the Product Owner, but be aware, this is not open for discussion anymore. (This helps teams to avoid being pushed into delivering more than they know they can commit to)
At this stage teak a break and then bring only the team back to the room where they need to decompose the selected items into tasks. The Product Owner is not part of this session as the team needs to candidly discuss and decompose the items, however, the Product Owner needs to be ‘on-call’ to provide clarification or renegotiations on items as they are decomposed. Once the team has decomposed all the items, your team will then have a Sprint Backlog and work can immediately commence.
Regards
Arrie van der Dussen
Agile Business Manager / Agile Coach
Kaizania
agile@kaizania.co.za
One of the perks of having a scrum coach in house regularly, is that my mistakes hardly ever go unnoticed . We have a regular meeting during which we discuss our own scrum implementation in Kaizania, and how we can improve the way we work. For me, this is one of the best things about scrum: you have never “arrived”, and can’t settle into a comfort zone, there is always something which can be improved!!
We had a meeting about a week ago, during which Arrie pointed out some things which we need to sharpen up on, one of which was the fact that we currently size our tasks, not only the stories as we’re supposed to. Now, even though I know it isn’t supposed to be done this way, we did it with good reason, and after having the discussion with Arrie, he understood the purpose of this, and left it at that.
The reason behind the unruliness was that we needed to size our tasks, as the stories took longer than a day to complete, sometimes up to 80% of the sprint duration, hence the burn down would be useless if we didn’t size the tasks. In the past we tried one sprint, without sizing the tasks, and it was chaos. The team attempted to estimate the work left during the daily stand-up, but their estimate was not even close to being accurate, and we ended up with a lot of work left two days before sprint end, even though the burndown chart indicated that we were well ahead of schedule.
To avoid running into that problem, we had the team size the stories during sprint planning, as it should happen. Afterward I, as scrum master, would divided the story size between the number of tasks, and so each task had a size as well (which made up the total points allocated for the relevant story). This gave us a much better indication of the progress made, and even though it wasn’t the perfect solution, it worked much better than estimating the amount of work left during the daily stand-up.
After my discussion with Arrie, we had a sprint planning, and one of the other areas which we had to work on was breaking our stories down. With blood, sweat, and some tears we managed to put together a complete sprint backlog with no story sized bigger than 13!! This was a huge improvement, as our previous sprints had stories sized as big as 89!!
Once we started doing the task breakdown, we realized that the tasks were much different than before, and there was no sense in sizing them anymore!
The problem was that with the bigger stories, we actually had an epic as the story, and the tasks were small user stories. During our first stand-up meeting, I explained to the team again how we do the estimation of work left, and this time around it went much better. Because our stories were smaller, the team was confident to size the work left, and this time around our results were much more accurate. Even more accurate than when we allocated a size to the tasks.
Danette Kok
Scrum Master
Kaizania
Over the years using and implementing Scrum in organisations, I struggled sometimes with the value of the daily-standup…
Why did I struggle?
- The teams started off excited and it worked, however, as the adrenalin rush dissappeared, the daily stand-up became a drag, something they had to do with no excitement and not a lot of communication or team co-ordination
- By asking every member to come to the front and answer the 3 questions, there was no cohesive drive towards completing stories from the top ( prioritised ), people were all over the board and it was difficult to see what is what
- The communication as a team was not good, there was no hype, there was no excitement and no drive towards a mutually accountable goal at all…
The Solution
Well, this may go against the books and theory, however, it works for my teams…
I changed to ‘walking the board’, and a lot of Scrum practitioners are now doing the same…
I asked the team to communicate and co-ordinate collectively on each story, one at a time, from the top ( highest priority ) and talk through each story as a team…
The Result
It worked! I managed to solve 2 problems with this…
Problem 1: No effective communication and co-ordination as a team
Problem 2: Working all over the board, instead of delivering stories as a team from the highest priority first!
By walking-the-board we manage to solve both… the teams are now excited, they communication extremely well, the focus together as a team on their mutually accountable goal and the best is that suddenly they are holding each other accountable for that goal…
Since, I have used this regularly when I encounter the above mentioned problems… walking the board provides a Scrum Master or Coach with a method to mature an Agile team very fast…
Please go to http://agile-commentary.blogspot.com/2009/04/walking-board.html for another Agilist who did the same…
Kind regards
Arrie van der Dussen
Agile Business Manager
Kaizania
Why commitment is so important
May 19, 2009 in Agile Commentary, Scrum Implementation | Tags: agile product owner, agile values, implementing scrum, scrum, velocity | by thinkingagile | Leave a comment
Trial and error has now repeatedly shown that it is not advisable to bend the agile methods. We have tried and take short cuts, or to make things work specifically for our situation, but time and again we’re brought back to the same principles.
As we know it is very un-scrum to NOT make a commitment during sprint planning – It almost defeats the purpose of scrum. We’ve been under the impression that our situation is very unique, and have tried come up with solution for our problem areas. The only plausible option seemed to do planning for a certain set of user stories, but not to commit to these. Instead we gave the client the benefit of being able to add other user stories midway through the sprint, which would have a direct effect on the team’s ability to complete the planned stories.
The reason for this is that the software being worked on is already in a production environment, which brings up a few maintenance issues every now and then, as well as customer specific change requests. For this specific project we usually run two week sprints, and if something pops up in the middle of a sprint, it’s just too long for our client to wait until the next sprint. I’ve heard about the swop out theory, and we have tried it, but this didn’t work well for our client for various reasons.
To get back to our non-committed sprint, the team obviously didn’t have any objections to this because it meant they didn’t have to take the responsibility, but since our two week sprints are paid for based on the amount of days, and not work done, this really didn’t benefit our client.
Our sprint ended with one planned user story outstanding, but since this wasn’t committed to it was perfectly acceptable to move this story to the next sprint.
This didn’t have any negative implication for the team, however our client didn’t get the functionality he bargained on getting.
During the retrospective we decided, together with the client, that we will not be doing another non-committed sprint.
This created a false expectation for our client, and when the team couldn’t meet up to it no one could take the responsibility.
The client has agreed to stick to committed sprints only, even though he will have to wait for maintenance and change requests a bit longer, it is definitely worth it.
This way he will know exactly what functionality to expect at the end of the sprint. In the event of an urgent maintenance request, the client can then decide whether to cancel the current sprint, or to swop it out with a committed story of equal size, which the team hasn’t started working on yet.
Regards,
Danette Kok
Scrum Master
Kaizania