I don’t know about you — but when you talk about stocks, or markets, or funds — the general rule of thumb is: Past performance is not an indicator of future outcomes. Have you noticed that is software engineering, we tend to this advice? We tend to use our to our and our . We like to look at to determine what we can achieve within the . Why do we ignore this commonly accepted rule of thumb from finance? Are humans and our efforts really more predictable than a market? I don’t think so — but I’ll dig deeper. ignore current velocity calculate next velocity future velocities past performance next sprint/quarter/year Recording Velocity One of the things you’ll find most “ ” teams doing is recording . If it’s not the team, it’ll be the . It’s their job to give some security to a business and be able to say what they think they can while . Velocity is normally (from experience) regarded as the number of your team can get “ ” in a sprint. Basically, you record this over time to get to a point where you can predict what the deal will be able to achieve next sprint (and beyond). agile velocity PO (Product Owner) achieve minimizing risk story points done P.S. I put done in quotes because every team’s definition of done is different. Your team needs to figure this out for yourself. Some previous definition of done’s I’ve had are: Merged to master. QA tested. Deployed to live. Development finished. Story points? Story points are of the required for a story. They should be associated with a . Obviously, there are to every rule. When you’re first estimating, you’ll probably end up using . But it should be a direct conversion. Generally, I’ve used T-Shirt size estimates and sometimes they have numbers associated with those sizes. You add up all your story points done and that will give you the velocity for that week. very rough estimates effort never time exceptions days not one-to-one XS, S, M, L (after large, the stories should be broken up), XL, XXL, XXXL etc. 1, 2, 3, 5, 7, 13, etc. Is Velocity Meaningful? Normally, when a member joins a team (or leaves), it’ll probably take around for velocity to . Why’s that? Because it takes a time for a team to build and to measure their performance accurately for their products. So, while you can record velocity, it probably until your team builds the trust. That said, it is good to keep at it during this first six months to build up the trust in the numbers. But can you ever trust the numbers completely? They’re just rough guides remember. Some stories might have hidden complexity. Over time, your team will figure this out and your estimates will improve. 6 months stabilize long trust won’t mean anything Using Velocity — what does it mean? You can’t compare two teams’ velocities. It just won’t work. One team may and one team may . will have for the teams. So why would you even use them? In my team at Agoda, rather than the PO (Product Owner) say what will be completed in a quarter to management, we work the PO to determine our past quarter’s velocity and can use that to give an of what we’ll get done next quarter. This means that you have ample stories in the backlog estimated. underestimate overestimate Story points different meanings with approximation Now, this does not mean that you’ll work day and night to complete what you committed to. No. This means that you can manage expectations of management and the team. PO’s are always coming up with ideas and changing plans. Guess what? You can (based on your estimates) stories out of your commitments if your PO changes plans all the time. You can say “if you add this story — it will probably remove the bottom two from the quarterly goals. Are you okay with that?”. The PO will most likely answer yes and you aren’t stuck with unmanageable goals. kick To Sum it All Up is a funny metric that be across an organisation. You can to use velocity to future commitments and/or sprints, but that doesn’t mean that it’ll be 100% accurate. Plans change all the time. People will come and go from your teams. However, it can be useful to predict what features you might want to include and how to them. You should use story points and time to base your estimates. Story points should not be related to time, but to effort. Lastly, figure out what your “done” is. Velocity cannot consistent try predict roughly prioritise not Originally published at www.alexaitken.nz on July 9, 2018.

Velocity

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Past Velocity and Prediction

Too Long; Didn't Read

Company Mentioned

Alex Aitken

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Past Velocity and Prediction

Too Long; Didn't Read

Company Mentioned

Alex Aitken

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES