Oh, that 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 the 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, 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 to erase all the points mentioned previously. ASAP. You just 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 ourselves in ScrumDesk while developing our own 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 maximum 3-5 days with everything included.
- UX is ready before the planning. PO and UX did they 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 Owner continuously and often accepts. In our company, almost daily.
- The product is integrated and set up daily, continually. At least for the testing stage.
And now, is something is so small, it’s unnecessary to evaluate the percentages, it loses the meaning by itself and naturally. All you have to do is to tell if it works or doesn’t. And 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, 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.
