The value of a feature can be determined by three variables:
Effort required (the lower, the better)
Alignment with company’s goals (the more aligned, the better)
Shelf life (the longer, the better)
Let’s compare two examples below:
A - A landing page that is going to take 5 weeks to build but will only be available for a week. The reason for the page is to announce a new product offering, as per company’s goals
Here is my unpopular perspective on story points. Story points are just a number. Don’t get me wrong though, it’s a good information to know for the team so that they can predict their velocity and commit to deliverables. #agile#scrum#developer#storypoints
The use of story points has always been a huge topic for debate. Some say it is useful for agile software development teams, others say it is of no use for business. Both of them are correct.
But here is where I have a strong opinion, as someone who has worked in many software development teams, both as a software developer and an engineering manager in the last two decades of my career. Story points are a bad measure for a software developer’s performance.
My take is that when you’re starting out in your career, you need to be a generalist. It will allow you to find a job quicker, get into your desired industry easier and you’ll generally have more choices.
As you get more senior in your career, you will need to start thinking about going deep and picking a specific niche.
While there is no set number of years, generally, 5 - 7 years in a software engineer role is what most engineering managers have before they take on the management path.
Some tech companies put senior engineers on the same level as their engineering managers for this very reason. Engineering management is a linear and alternate career track to software engineering.