"to deliver value to somebody"
AGILE & sprint planning (and generally planning) are for fighting human impulse to avoid confrontation, to waste time and be unfocused. In development this is called "waterfall". I call it "programming instead of working".
EXAMPLE - "disorganised" development in a company
- customer says 'i want a "thing"'
- company's tech team spends 6 months programming the product, after 6 months shows the product to the customer.
- customer says "no, not that thing"
EXAMPLE - groupwork in a school course:
- teacher says "the purpose(value) of this group project is to learn to communicate and work in a group"
- with no planning, students say "let's split up, ill work it out, let's evaluate and organise our code 1 hour before presentation"
- project doesnt work, no usable resulting code
SCRUM is the complete opposite of this way of working. You get as-frequent-as-possible FEEDBACK from your team, developers, customers, to make sure you're doing the right thing and not wasting time.
a big list of things the customer needs in total, that describe the whole project ( lots of user stories )
small chunk of time during which you work on the most important stuff in the backlog.
During this time only write code to deliver usable things to the customer.
sprint planning always goes in this order
- the customers next priority need is X (eg. login, optimised mobile site, PWA)
- "how do we deliver a usable solution for that priority thing during this sprint?"
- you decide how many subtasks of that next prioritised feature you can do.
during the sprint
- do all the steps (or as many as possible) to deliver that value.
- Work only/first on those tasks.
If you're writing any code, but it has no connection to the selected tasks from planning and the priority user story, then STOP.
If you're working on a user story, but you say "this login feature won't be finished for 2 months, then the customer can try it", STOP.
You need to deliver small incremental improvements that the customer can actually check and give FEEDBACK on. Even if it’s not the whole thing, it needs to be a small observable, useful improvement.
EG. ( "Hello customer. We know you want 5 different login types fb/email/phonenumber/slack/github, so we have delivered during this sprint the email login. What do you think?" )
If you don't do this, you're flying blind with no feedback and potentially wasting months.
customer says
"I would really like to login to the website with a phone number, as my user demographic doesn't use facebook login"
you should focus on all the requirements of that feature that are necessary for the customer to test it and give feedback. Consider this “vertical” approach.
- show the login / registration views, profile views
- register/login/SMSconfirm routes,
- User DB schema, password hashing function,
- SMS to confirm user owns that phone number,
- write new user to database
- new table - “user”
This is a “vertical” line through the tech stack, to provide at least the absolute bare minimum for the customer to realistically benefit from your work, to test it and provide feedback. ( maybe there are some tasks you could remove to focus on providing the main usable value to the customer?.. (eg. profile page) )
.. if you don't focus in each sprint on delivering usable features, the customer can't give meaningful feedback, and you're at risk of slipping into waterfall territory.
The login UI, by itself for example, will never alone be useful.
Success isn’t based on hypothetical benefits, and customers can’t measure the value your work on "eventual" “it’s gonna be good in 2 months” value.
customer says
"my website is slow - i would really like this website to load extremely fast on mobile phones".
think “vertically”, big picture. Goal: make website fast.
- delete all the unused HTML
- reduce the number script tags in the HTML (or defer download after html is loaded)
- make the API simpler (reduce middleware in the API, so the server responds faster)
- use a service to "serve" multiple copies of your website from different places in the world eg. South Asia, SeA, EW, EE, NA
- optimise image/media sizes - send tiny images to mobile phones, 4kb instead of 1mb
In the above example, you could argue that all these improvements are isolated, and are not co-dependent to be effective.
You could do any of them alone and deliver some real measurable value. Though some of those steps are vastly more effective than others.
In summary, a smart company should be focused on delivering real usable features and value to customers.