Beyond Story Points and Velocity Graphs
Coming from a services company, for last couple of years we all have been fighting with clients over points , velocity and scope. This talk is about how to think beyond points and still create visibility to the clients and how we did this in our project ( which was a distributed agile project beased out of India and Australia )
Outline/structure of the Session
Learn how we moulded agile for our projects, and how can you do the same.
BA , Devs , QA , PM
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Should we stop using Story Points and Velocity?Prasanna VasteBusiness AnalystThoughtworks
schedule 3 years agoSold Out!
On Agile projects we estimate user stories in order to allow team to
- 1. Track velocity
- 2. Decide scope for the Iteration
- 3. Help Prioritize stories
- 4. Help Release planning
But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.
Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.
I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.