Today we’ll share with you valuable advice from Lori Arche. Lori is a Senior Director of Program Management at Fandango.
She has over 15 years of Project and Program Management experience under her belt with a focus in eCommerce development.
Check out Standuply Mentors, a new learning platform with hundreds of experts ready to share their knowledge.
We asked Lori to answer one of the most difficult questions in scrum and share her experience.
Today’s question: How can a team move away from the task estimation in hours towards story-points?
Lori’s answer:
I’ll just go through how I solved this problem using Fibonacci points.
Standuply note: In Fibonacci sequence each number is the sum of the two preceding ones, starting from 0 and 1. This video briefly explains the essence and properties of the Fibonacci numbers.
Velocity
First, I presented the problem by looking back at the team’s velocity based on their hour estimations.
Let’s wonder that your team’s probably experienced the problem when the number of hours is significantly less than the people on your team.
For example, we had a velocity of only 30 hours, but we had a five-person team. So you would assume five times forty would be 200 hours give or take (remember that not everybody works 40 hours a week).
In between somewhere 150 to 200 hours a week (or if you’re doing weekly Sprints) you would have the team’s hourly velocity, but now we would only have 30 hours.
I presented past Sprints that showed that the hours weren’t very accurate. I also provided example projects of them not meeting their milestones or the team having to rally at the end to put in a lot of hours.
I even showed poor burn down charts to them. I presented the data of the problem and why I didn’t think that the hours’ estimation was working.
Then, I would present them with the benefits of story pointing. Fibonacci tends to be more accurate because it’s inclusive of ALL team members.
Depending on your team, you might have QA or have front-end and back-end development.
It’s inclusive of all team members contributing to the work so it’s more accurate. It also takes into complexity and ambiguity which sometimes our forecasting doesn’t.
This accuracy helps with forecasting your project plan which makes it easier for everybody.
They can prepare future Sprints when they have free time, so if the team hits their goals and they exceed Sprint expectations it’s super easy for them to pull something from the backlog that’s ready because the product manager can prep future.
Sprint Planning based on the team’s velocity makes Sprint planning super smooth: if you already have a team’s velocity, you just are pretty much reviewing what they had groomed in the previous grooming or refinement session and pulling that number of points in.
Having an accurate project plan reduces stress on the team because you’re hitting your milestones and makes the project and product managers’ jobs easier.
Lori Arche
Sr. Director of Program Management at Fandango
Review this data with the most influential people on your team to gain confidence and get your team to agree in moving forward after knowing the problem and presenting the benefits.
On this step, I would think through who are your influential players on your team and set aside some one-on-one time with them.
After that review the problem and the benefit with them, and collect their feedback as to why they would be resistant to moving forward.
Start asking your team questions and instead of creating conflict, think of questions that you can answer that basically will help them come to their own conclusion that there’s really no reason not to try this.
Think through what their concerns would be and ask them like, “Why do you think Fibonacci would cause that issue?” Just keep driving them with questions, and I would think eventually they would come to their own conclusion, “Why not try it?”
Other questions: “What do you like about hours? What about pointing doesn’t do that?”
And make sure you’ve done your research and have all the benefits and problems with hours primed and ready for this.
Retrospective meeting
Once you’ve addressed all the concerns with those most influential people I would do a team meeting.
On this step, you can use your Retrospective time to present these problems and benefits and run Retro meeting.
I would talk through the concerns of just doing a two to three month trial period of trying this Fibonacci approach.
Make sure you explain to them that you have a methodical approach: you’ll get the team to practice estimating before moving forward.
Lori Arche
Sr. Director of Program Management at Fandango
You’ll be monitoring the burndown daily and the team’s velocity with every Sprint, and then you guys will be adjusting as you go along in your Retrospectives.
Planning Poker
After getting their agreement confidence I recommend a pointing exercise called Planning Poker.
Standuply note: In classic Planning Poker, if all estimators selected the same value, that becomes the estimate. If not, the team discusses their estimates. The high and low estimators should especially share their reasons. Then the process runs again until all estimators provide the same estimate.
Lori uses her method:
- Document best practices for using Fibonacci sequence and review them.
- Write down the Fibonacci series on post-it notes.
- Take your most recent previous Sprints.
- Order them from easiest to hardest
- Then point the easiest to hardest
- Write those user stories on post-it notes.
Maybe you could do this for the past one to two Sprints, depending on how many cards are in each Sprint. Write the stories on a post it note.
Then I would have the team start working as a team by ordering those cards in a line on the table from easiest to hardest.
And once they pointed those in the line you could start from the easiest card and use it as an example of a 1. Then move to the next one, “Is this a 1 or a 3?” and then just move along the line from easiest to hardest.
I actually also do this easiest-to-hardest process with any large project I have.
Make your team organized! Try Planning Pocker via Standuply.
Especially, if stakeholders have said like, “The third party has asked us to launch this project by a certain date. Will you be able to hit this date?” I would do this exercise using high-level stories to determine confidence. It should only take 1-2 hours.
I’ll set aside about two hours with the team and we’ll do this quick grooming exercise to groom and point the project with a hard deadline.
And then identify Sprint goals for each large project and do a similar process but with cards you’ve already completed so the team is familiar with them and so they could point easiest to hardest.
That also gets them in the routine of practicing points and working with the other members of the team to point.
After that, the team will have their practice and you will have your examples.
So in your next grooming meeting when you start to roll out pointing new cards, you’ll put these examples up on the board so that they have a visual indicator of what they’ve pointed so if you run across a similar card you can say, “Oh, in our pointing meeting earlier this week we pointed this as a 5 (or a 3)”.
This will also help your velocity be more consistent if you were pointing similar cards very consistently.
It’s good to have these examples and keep bringing up examples from previous sprints into your groomings so that you’re pointing them consistently.
You can use other best practices to make sure there’s a smooth rollout. Always present your team such information as:
- Metrics
- Burndown charts
- Velocity
- Cycle time
This way they can see the fruits of their labor, and they’re pointing, and you can adjust accordingly.
Keep the visual indicators of how you pointed things in the past so you can point cards consistently.
Another best practice would be to not point over an 8 or a 13, depending on how long your Sprints are, otherwise break it down into smaller cards so that your cards would be more accurate.
If any cards do carry over Sprint to Sprint, make sure you’re repointing those cards based on the remaining work for that next Sprint.
That will make sure that your velocity is also more consistent, that it doesn’t have this up-and-down based on things that have carried over.
I definitely think it’s important to present the problem, present the benefits to the team and how exactly does this benefit them.
Lori Arche
Sr. Director of Program Management at Fandango
Get the most influential people to buy off on this change, present your methodical approach to rolling this out.
Sometimes people have more comfort knowing that things are a trial, but make sure your trial is a long enough period that you could get your people comfortable with. And then measure and go from there.
