The the oh-so-common 2 hour+ full team meeting scoping session, where half the team dosen't care what the other half is talking about since it's irrelevant to them - it tires everyone
out and produces very little value for the impression of "we're now aligned".
Things only need to discussed if, when and only by as many people as required, everything else can be followed up later, it's really okay. Personally, I've always found things like 3 amigos to be much more time effective.
In my experience AB testing has a time and place - and that is after a certain level of traffic load and product/feature maturity and only to "validate" certain hypotheses.
For low volumes of traffic AB testing would takes ages to wield significant results and for products still maturing and shaping there is lot of "wisdom of crowds" data already available to help make decisions faster (ie: do you really need an AB test to know offering timely promotion to users helps convert?)
If you got a young product trying to grow, fast, it's a lot more effective to rely on experienced product people and off-the-shelf simple analytics to iterate quickly and to take some bets so one day you get to a point where AB testing "optimisations" starts to make sense.
It's a quite an interesting topic! I agree with you too - A/B test driven sites tends to culminate in terrible "cumulative experience" for users
Plum Guide | Backend Engineers and Frontend Engineers | Fully Remote (Europe & UK Only) | Full-time
Plum Guide is on a mission to solve the uncertainty of travel. We find and curate the best home on the planet, using a mix of humans and machine learning to help our guests find the perfect stay, every time. We’ve been focusing on scaling and launched 150 new locations in the last 6 months.
We are hiring engineers who care about our customers and want to help us scale the company, our engineering team and culture. Our teams are cross functional and highly collaborative, our engineers work very very closely with product, design and data.
We are big fans of “DevOps culture” and continuous delivery.
Our stack is always evolving but it’s primarily composed of:
On frontend we are building using React 16+, NextJS, Stitches, Storybook, Nginx, Jest.We are also working with designers to shape our in-house design system.
True, I do find it easier and a less time consuming to break a large piece of work in around 2day chunks (for example) than using different sizes or trying to decide if something is 3 or 5.
In the end, regardless of whatever scoring strategy you use it should always be team centric, rather than individual.
It is possible to say, over the past 6 months, and X tickets, our team has had a Median/Avg cycle of around 2days. If team breaks future work in similar sized chunks, it can very fairly confidently predict how long they will take to do X more tickets, assuming similar conditions.
The added benefit of using small chunks of time, is that one does not need to be super accurate (in most scenarios), it can be 1 or 4 days, all it matters is it's possible to give window of estimation (based on actual data, not guesses) with a certain degree of confidence. (which will naturally become even more consistent over time)
Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity (which one can use Cycle time to calibrate)
Even neater with enough data it becomes possible to use Monte Carlo simulations to give you confidence intervals on how much can you do or how long you will take to do X amount of work.
The the oh-so-common 2 hour+ full team meeting scoping session, where half the team dosen't care what the other half is talking about since it's irrelevant to them - it tires everyone out and produces very little value for the impression of "we're now aligned".
Things only need to discussed if, when and only by as many people as required, everything else can be followed up later, it's really okay. Personally, I've always found things like 3 amigos to be much more time effective.