Story points – What does it mean?

Posted on Posted in management

We’ve just got a brand new Product Owner in our team! That’s really great! He knows the business domain, feels passionate and dedicated about new role (at least for now 🙂 )

Having a dedicated product owner who is focused on one team is extremely important for the overall team’s success.

But… our Product Owner is new to Scrum and is not aware of different planning and estimation techniques we use in our team – Story Points is one of them.
As the result quite obvious questions raised:

  • What are those story points?
  • How can i predict releases based on such estimates?

I used following short statements to explain the main essence of estimation with Story Points:

  • First of all story points are relative measure and please do not compare estimates with other team
  • Story points represent the complexity, effort and scope of the item. The higher the estimate, more effort it requires or more complex the item is.
  • This number includes everything in order to achieve company’s/team’s Definition of Done. Done means generally the following: tested, properly documented, has value to end customer, ready for production
  • Team’s throughput (velocity) is measured based on performance of e.g. last 3 sprints. And it means that this is the total number of points that can be included into sprint.
  • You can predict/plan future (release) based on historical data and high level estimates with story points.
  • You cannot force the team to change the estimates. You can only change priorities, scope based on information team shared with you.
  • Remember 3 != 3 !!! It is very important! (For some reasons it was very clear to him, although i expected a long debate here :))
  • High estimate (e.g. 13) might mean following to you. You have at least to options: item requires additional analysis and needs more detailing; item is very complex and just requires a lot of work
  • Last, but not least – Trust team’s estimates!

These short comments helped him to get this initial understanding of what is going on.

P.S. Encourage your teams to help your Product Owners in order to achieve common understanding about team’s throughput

 

Largest impediments

Posted on 1 CommentPosted in management
Have you ever thought about the largest impediments while working according Scrum?
I personally encountered following largest impediments with teams i was working.
Story points and relative estimation
We realized that it is very difficult to separate time and size while making estimates for specific tasks. Another problem related to this issue is trying to be very specific while estimating with story points. This led to a lot of misunderstandings at the start. It’s quite difficult to realize that duration of implementation might differ for both tasks estimated as the same size. 3 is not equal 3 !!! 🙂
The very first team’s impressions was – How can it be?! So, it led to a frustration at first. But one thing helped us a lot – we made an analogy to simple physical formula: V (speed) = S (distance) / T (time)
We agreed on meanings for formula’s elements. 

V is team’s velocity and it can change over time. We can go faster or slower which depends on situation – someone i sick, we face a lot of impediments and etc. Team’s goal is to achieve constant/predictable speed.

T is our fixed sprint time box (2 weeks)
S is size of our features that we want to estimate. It’s a common thing to measure destination in meters (Europe). So team’s goal was to identify “our” meters, to make it easier we took some already implemented tasks as standard for our measures.
Analogy with meters also helps to explain why 3 is not equal to 3. Imagine that someone asks you to measure a distance from your home to work and lake nearby. You might say that it is about 9 km to both destinations, but when you measure actual distance (traveling the distance/taking item into development) you identify that distance to you work is 8,5 km and distance to the lake is 10,1 km. So, initial estimates are not equal, they only help you to have an understanding of size!
After we applied this rule several time it became very easy to estimate by story points. Btw, we used Fibonacci.
Agile (not only?) development practices
I mean automated testing, integration testing, developers do testing, and etc. Why “not only?”, well i think these practices are applicable everywhere.
Our quality reduced dramatically during first sprints. It should have been expected result since we were developing more than we were actually able to test and verify. Developers refused to test. It led to very simple thing – while one feature was developed another stopped working.
It was a nightmare, team started to blame Scrum, we couldn’t finish product backlog items properly, everybody was disappointed.
We did the following. We reduced speed (velocity) and dedicated some time for test automation and integration testing. The team was surprised how much value it gave them. They were able to detect problems in advance and in no time. It was a break through, team saw the value and they started to apply automation everywhere they could. And developers do testing, but in a different way.
Communication with other teams
I faced very interesting problem at very early stages of applying Scrum – people started to avoid helping other teams despite the fact that they are working for the same project. Team members were focused only on their own goals and they were afraid of doing anything else except what was planned in the current sprint.
This issue helped us to identify one simple problem – cross-dependencies were not identified properly by our product owners. We increased cross communication among the teams to be able to detect possible dependencies as soon as possible. Cross dependent items are included into the same sprint for several teams. Joint planning sessions and cross team short meetings are organized in a periodic manner (Scrum Masters can cancel those meetings if they are not relevant for the current sprint).
I again was curious what other people think about this topic and what impediment they have encountered. I started a topic on the scrum alliance group. You can read all the answers in details here

  • Writing good user stories – clearly
  • Let the developer do the estimates
  • Functional managers try to control their “resources”
  • Interference (intrusion)
  • Team contribution during sprint planning
  • Some members tries to force only their way.
  • One way communications
  • Estimating tasks with huge buffers
  • Management offers no time for the team to learn, with deadline pressure as the reason
  • Fear and habbit (no willing to change)
  • Misconceptions about Scrum
  • Contracts not adapted to Agile
  • User stories not completely “done” at the end of the Sprint
Do you recognize yourself here?

User stories – size of story points

Posted on Posted in personal improvement
How to improve estimation with story points?

Story size before sprint

  • Keeping stories small is very important.
  • Keeping them substantially smaller in size than the Sprint length is very important.
  • Keeping them about the same size is somewhat important.

Story size after sprint

  • When something takes /more time/ than estimated, there is learning
  • to be done. When it takes /less time/, not so much.