And large tech companies like FAANG (Facebook, Amazon, Apple, Netflix, and Google) have documented information about this expectation, so in a way, it’s very objective.Ĭommon competencies (in order of expectation by junior -> senior) are:
Define story point measure software#
Tech companies tend to measure the performance of their engineers and software developers against the competencies expected for their level and role. However, this sounds a bit abstract so let me explain further. They should be measured by the outcomes produced.
In terms of percentage, it will be close to or more than 50%, depending on the size of the company, the complexity of the project, and seniority.įirstly, let me get this out of the way: an engineer’s performance should never be measured by the number of hours worked or line of codes written. This is especially true if they are working for a large tech company as there is a lot more coordination and knowledge sharing required.
Define story point measure code#
Senior engineers may have less coding timeĪs an engineer progresses in their career, they might find that actual coding / development work is less and less as they will be doing other things require more seniority such as planning, story breakdown, mentoring, onboarding, code reviews, etc. I understand many software engineers do not generally want to commit to a deadline in case they discover any unknowns but not setting expectations on when something will be done, or not having any milestones is purely irresponsible. The worst thing about story points is that it enables software engineers to avoid committing to any date. Sure, they may work on the most complex (relative) stories, but that doesn’t mean they are doing their best, delivering on time, and embodying the right behaviours. Story points do not tell us how accountable and reliable a software engineer is. Story points give away too much flexibility and encourage less accountability Not how much code they are writing or how complex their code is. The best way for an engineer to know how productive they are is to look at what outcomes they are delivering and the impact they are making to customers. Often, large story points are a result of complex code paths, and rewarding large story points indirectly encourages software developers to think complex and over-engineer their solutions. In software development, simple is beautiful. Larger story points don’t mean a bigger impact Therefore, when you’re comparing multiple engineers from different teams on their delivery, story points are not the right metrics to be measured against. Therefore, one team’s story point of 3 might not equal the other team’s story point of 3. Story points are the measures of complexity relative to the knowledge of the person or team giving an estimate. Why is the story points a bad indicator for performance? Not all story points are equal
Story points are a bad measure for a software developer’s performance. 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. Some say it is useful for agile software development teams, others say it is of no use for business. The use of story points has always been a huge topic for debate.
0 kommentar(er)
