Hot answers tagged

182

Good answers so far, but they don't cover all the bases. In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living. BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...


69

I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is ...


43

Yes but with a lot of care! Let me clarify that. You should strive to improve the habitability of the software. If you look at the code/team/business/project/management and your first response is to take a shower, then it is not habitable. If your first response is to shout yeah!... and then complain when you are turfed out of the office, then you need to ...


20

You're right - 5 hours in Sprint Planning for a 1 week Sprint does seem like a long time. The Scrum Guide time-boxes Sprint Planning to 8 hours for 1 month Sprints and says that "for shorter Sprints, the event is usually shorter". If you consider the ratio, a good target may be 2 hours of Sprint Planning for a 1 week Sprint, but there's no fixed timebox. So,...


20

Yes You can. BUT... You have to be careful. At the begining of my career (very long time ago) I was lucky/unlucky to get into a few months old project as the "Junior". As the first thing I noticed, there was (OMG) no code repository! All merges of code were done manually by sending zip files to each other by mail. So I went to my (also new) manager and ...


16

You are correct, there is not a formula to convert story points to hours. You can get a pretty lossless conversion of meters to feet, and vice versa, but you can't say a 3 point story will take X hours, so a 5 point story will take Y hours (solve for Y). HorusKol touched on this next part. Your sprint velocity as a team can help out with the longer term ...


16

When all teams define "Done" in a manner that takes into account work completed by other teams, then you are ensuring functionality is complete. If each team defines "done" differently and just expects the other teams to know about that definition, you'll run into several problems: When an integration problem arises, no team will want to take charge of ...


14

Your back-end table stories no longer require eight points of effort. “A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“ scrum.org If you continue to estimate back-end table stories at eight points then you will skew your velocity as a ...


14

Is it worth a (junior) developer's effort to try and push for the above as time goes on? Yes, it is always worth your effort to try and make things better. You know best what problems you face after all. But as you mention, there are lots of problems to solve and many of those problems are not terribly valuable. And at a lot of places, there will be ...


12

Slowing one worker down would be a very poor choice. Things I would consider: See if you can rebalance the workload. Some things aren't clearly front end or back end tasks, and you can shift more of the burden to the programmer who is running ahead. In this same light, there is no magic about front end versus backend work: especially as they share a common ...


12

Yes. But organizational change is hard even for a senior so if you really want to make a difference do it in the right way: Not during the first weeks: Use this time to: Create a good first impresion. Show that you fit in the team. Understantand the culture and politics or your company. Is it safe to push for changes? Build a good relationship with ...


12

The very short answer is that yes, Scrum is by design a more expensive approach, but if you're calling it a project, it almost certainly doesn't matter and in the end will almost certainly always result in a better ROI. The more complete answer is this: Generally speaking there are three forms of process control: Defined Process Control, Statistical ...


11

It sounds like you are at the extreme thresholds of Scrum. According to the Scrum Guide, a Development Team that has fewer than three members has less interaction or doesn't need as much interaction as a slightly larger team. Therefore, you may not see benefits from using the Scrum framework in a way that slightly larger teams would. It also sounds like the ...


10

Your numbers actually seem to have your expected distribution, though it's hidden by the log-scale. You might get better intuition with a plot that illustrates the density, e.g. a violin-plot. A box-plot can quickly provide a few summary statistics which are not obvious for your data. Comparing the median might be better than comparing the min/max, as the ...


10

whether the notion that sprints/iterations in agile development should always be back-to-back Yes. A Sprint is timeboxed, and the next sprint starts right after the previous one's timebox ends. This provides the cadence and rhythm of a Scrum sprint. with only a review and planning meeting to separate them from each other Reviews and Retrospectives are ...


10

Increasing velocity is not a goal. The goal is reliable planning. Story points are a tool in a feedback loop that will tell you, over time, what your typical velocity is. This will then tell you how much points you can realistically adopt in a sprint. Velocity may drift a bit over time but if it changes too quickly it is useless. A sudden increase in ...


9

If at the end of your sprints often you have many big tickets that are 90% - 95% done then there is something wrong: Red flag #1: Lots of things get packed into a sprint but are not finished Red flag #2: You have many big tickets Red flag #3: For some reason this affects the "last" 10% of progress Let's adress those things first: 1: If you repeatedly have ...


9

There's no prescribed way to document Retrospective feedback, but there are some things to consider. The most important thing to consider is that the team needs to be able to be open and honest. If you are using an electronic tool and requiring people to complete retrospective notes before a meeting, then it is likely that the authorship of those notes may ...


9

Yes. But not the things you suggest. Out of your list Unit/Integration tests are the only item you can make progress on. You can start adding these by yourself with minimal time investment and show instant value. Its a technical problem with widely accepted benefits and wont affect others work practices. While also gaining you mdore knowledge of the code ...


9

Sure, if you have a project where you have crystal clear requirements up front, then you could waterfallishly dump them in front of developers and come back two years later to meet the software of your dreams. But the vast majority of software projects is not like this. Usually, the customer doesn't know what they need. They are unable to provide complete ...


9

My first suggestion would be to fix your terminology to improve communication, both internally and externally. You are using terms like "Scrum Master", "Sprint", and "Sprint Review". These are terms from Scrum. Scrum is a well-defined process framework with specific roles, responsibilities, events - it has rules and those rules are defined in the Scrum Guide....


8

You probably already have some inherent conversion from story points to time estimates - how do you decide that you've picked enough work for your sprint? You've probably said something like "the team can handle 20 (or 40 or whatever) points a week". After a few sprints, you should be able to revise that based on completion - so now it's 15 or 25 (or 35 or ...


8

My recommendation would be to remove it from the current sprint, and then continue the sprint as usual. Don't "backfill" the sprint (though, I'm not 100% certain by what you mean by that). If you finish everything before the sprint is over, at that point you can do what you normally do when you have extra time, which might be to bring in one more small story....


8

No it does not. Only thing it states that at end of sprint, Potentially Releasable Product Increment is produced. And general consensus of "Potentially Releasable" is that it does include it being completely tested. But how team achieves that is completely up to the team. In practice, I find it hard to imagine that fully tested "potentially releasable" ...


8

The biggest problem I see with this is that you're looking at a mini-waterfall rather than a sprint. The description you're giving above forces the team to deliver all or nothing. What if they have 12 items in the sprint and deliver 9? Does that mean you won't test or release what has been done? If so then I dread your release schedule, every time any team ...


7

No. Scrum is designed to fight exactly the issues you are experiencing. You could switch to a reactive approach fixing bugs as they are reported as quickly as possible, but this comes at the cost of predictable completion dates and often the stability of your software. I would say you should push back, ensure all requests go in the backlog and are ...


7

The economical viewpoint is in principle on the shoulders of the Product Owner (PO), who is interested in maximising the value that is delivered, and is business savvy. He/she does so by proritizing the product backlog items. The Development Team is committed to deliver working software and implement product backlog items negotiated in the sprint planning ...


7

Make your fast developer learn how to do 'front end' tasks. Splitting developers up by language or framework experience is just something HR does to make it easier to advertise for employees. In real life developers are, or should be, constantly learning new languages, frameworks, software tools etc. Not letting some developers work on a subset of tasks ...


7

In my experience, bugs come in two variants: Needs to be fixed like... yesterday. Red blinking lights. Sirens. Bosses demanding a status. Oh. Yeah. We are gonna fix it. At some point. Maybe. In the first case, it is what it is. This does not care for "Sprints" or planning or velocity or points. It needs to be done ASAP and it will ruin your plan. There is ...


7

I see two possible options. First, don't break down the item. In this case, the work item (the story, ticket, whatever) represents the minimum valuable delivery of the work and can be estimated by the team and worked on. The team may break this out into subtasks (either in a tool or informally) and work on it, but the work is tracked at the level and is ...


Only top voted, non community-wiki answers of a minimum length are eligible