In out project the workflow of user story is ToDo - In progress - Dev - SIT - UAT now the challenge we are facing is in calculating the velocity Because we give sorry point considering the effort involved in development, SIT ,UAT testing. But at the website is sprint we are able to just push our user story to dev and not able to complete SIT and UAT in a sprint. Now what is the right approach to calculate velocity ?
Asked
Active
Viewed 340 times
3 Answers
2
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.
As you are not completing stories, your velocity is zero. If you keep a project burn-down you could see some earned points when you complete the SIT/UAT. This could give you an idea how much work is done and when the project is completed.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint
Guess you need to figure out how to get your work DoneDone within a Sprint. The idea is to really finish work in a Sprint, this can be a challenge, but experiment with reorganizing your work to make it happen.
Wouldn't it be nice if, once you finished a story, you never had to come back to it? That's the idea behind "done done." A completed story isn't a lump of unintegrated, untested code. It's ready to deploy.
I would take some time during the next retrospective and discuss how you can complete stories within the Sprint. What would it take?
I would suggest Swarming a single user story and getting it DoneDone, before starting the next.
Note impediments and fix them to deliver faster:
- If you cannot execute System Integration Tests during the sprint, invest time to make it easier to deploy to a test/staging system.
- Schedule regular time with users todo User Acceptance Tests, or invite them to the Sprint review and let them play around with it. Create new stories for things they find.
- Try splitting stories to make them smaller, so it easier to get the really done.
Niels van Reijmersdal
- 2,038
- 1
- 20
- 36
-
1A velocity of 0 makes it very hard to forecast. If you're unable to change the way your organisation works, you may have to settle for measuring the pace at which you can put stuff in Testing and do some shadow book keeping. There are all kinds of dangers associated with that, but you may need it for a while to learn how to adapt the delivery process in your organisation. Also, make sure you're not putting bad quality in Testing. Do all the work to make sure they're not going to find issues there. From there: Inspect and Adapt. You'll get there in the end. – jessehouwing Sep 03 '18 at 10:29
-
"If you're unable to change the way your organisation works, you may have to settle..." very true, but don't give up to quickly, as it is easy to say this doesn't work for us, instead be proactive and self-organise to make it work. Together with your Scrum Master try to break the status-quo. – Niels van Reijmersdal Sep 03 '18 at 12:02
-
I totally agree with that. Breaking the SIT/UAT dysfunction is hard as it's usually tied into the way projects and contracts have been setup in orgs. Look for ways to involve your users earlier int he process. How can you build things that they want to approve, instead of have to test to see if it matches their expectations? – jessehouwing Sep 03 '18 at 12:28
-
I agree with your points. Having said that few constraits I have are as below - I need to calculate the velocity per sprint - Cannot split user stories any more to fit all activities in a sprint - Having said that **CAN I FOLLOW SAFE HERE** instead of agile? If yes please help me with how can I implement the same here – Arjun Sreepad Sep 04 '18 at 01:38
-
Really? Even essential SAFE has continuous deployment ( https://www.scaledagileframework.com/continuous-deployment ) and Agile leaders ( https://www.scaledagileframework.com/lean-agile-leaders/ ) that should help you ship software every Sprint. Ofcourse you can split it smaller, just try harder. Talk to the people feeding you the stories and explain to them they are to big to complete in a Sprint. Talk about the impediments and resolve them. Giving them a fake velocity number is not going to solve your problems, unless you want to lie and be done with it. Make up some velocity number. – Niels van Reijmersdal Sep 04 '18 at 05:58
-1
My recommendation would be to measure number of storypoints thats been taken from the start of your workflow to the end of the workflow during a given timeperiod(Days, weeks, months etc), that will give you the teams velocity in storypoints.
Tim Carno
- 311
- 1
- 2
- 7
-
I Cannot do that. I need to calculate the velocity for entire user story – Arjun Sreepad Sep 04 '18 at 01:41
-
-
Thats what i mean, sum up the points or number of stories that you have managed to finish(bring to the end of your workflow) for a given time. Thats your teams velocity for that period. – Tim Carno Sep 05 '18 at 06:42
-1
What if:
integration testing is fully automated
if not, you have a tester full time in your team who tests as soon as a story is deployed on the SIT server (automated deploy by Continuous Delivery tool like Jenkins)
someone is accepting a story as soon as a developer says “take a look at it” (can even be done on your laptop)
the product owner is the person who accepts a story
in the Sprint Review (“demo”) you show the new Produxt Increment to users and request for feedback
... then you get flow and you have only three statusses: To Do - Doing - Done. And releasing/deploying to production is just another Story in the sprint.
... then Jira tells you your velocity and you can use all those other very helpfull reports in Jira :-)
... and everyone in the team is happy because there is flow. And features are delivered fast to end users.
Léon Tebbens
- 81
- 1
- 5