Oh, that’s a great idea once again. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%. Apparently, the feature is 79% done. Round of applause, that’s a nice number. Nicer than 78%. Masturpercentobation. But what Jeff has to do with that, yes, that user Jeff.
Team: ‘Ugh nothing we can do now, we have to wait 3 weeks for the next sprint release.’
Product Owner: ‘Hmm what if you, therefore, had nothing as well? A real ZERO|NULL|NIL|NIČEGO on your paycheck?’
Team: ‘Are you mad? Are you really not going to pay us for all this time we’ve worked our socks off? We were working unbelievably hard.
Product Owner: ‘Try to sell this to a client, then and don’t forget to remind him to pay. And that he’ll get the rest in 3 weeks. And BTW, we already know that we can’t make it, right?’
How would you feel if this is how you’d get your car repaired? Pay now, but you can’t drive it. Wait for three weeks. Would you want that?
That is not possible
So next time, use normal binary logic, as you were taught at school. 0. 1. TRUE. FALSE. Done, not done. It cannot be done? Why? Yeah, Yeah, I understand.
Because it’s a big requirement.
Because we’re waiting for the others.
Because it cannot be deployed now.
Because it cannot be committed because the other thing is not finished yet.
Because we don’t have integration.
Because it needs to be slightly modified.
Because, because, because.
Are you done for now? Now, start erasing all the points mentioned previously ASAP. You have to want to do so.
The world on the Agile side of the shore
It’s easy for me to say, right? Yep, ano, yes, 是的, да, sí, oui, yes, sim,نعم, yebo. We went through the same issues in ScrumDesk while developing our products.
So how can the world look on the other side?
- Product Owner splits requirements for smaller ones even before planning. They are big for a maximum of 3-5 days with everything included.
- UX is ready before the planning. PO and UX did their pre-work.
- PO has also prepared acceptance criteria with possibilities Must, Should, Could from the users’ perspective.
- He went through the requirements and acceptance criteria with the team.
- The team estimated user stories in story points.
- He divided user stories (if necessary) so they could be achievable and, at the same time, made sense.
- The team is doing branches like written in the book to Git.
- And because stories are small, they often merge.
- Product Owners continuously and often accept. In our company, almost daily.
- The product is integrated and set up continually daily at least for the testing stage.
And now, if something is so small, evaluating the percentages is unnecessary; it loses its meaning by itself and naturally. All you have to do is to tell if it works or doesn’t. Then, set on, maybe even sell and maybe make some money for the next requirements.
What is still to be taught? Next time, we’re going to look at user stories, splitting, story points, velocity, correct git structure, and acceptance.
A couple more toothed wheels, and you’re doing it.
P.S. Remove the percentages immediately. Admit your color. Done or not done.
P.S.2. Really. Forget percents. Welcome Done.
