Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

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 ...


89

If you are using Git, each developer would be pulling from the develop branch into their own feature branch so that they ensure they don't go too far from the current baseline. They can do that daily, so that tasks that take more than a couple days stay in sync and merge issues are resolved while they are still small. When the developer is done with their ...


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 ...


57

This has nothing to do with Agile or Scrum. The problem with "duct tape it now and we'll fix it later" is that later never comes and in the mean time you are accumulating a lot of technical debt. The first step to recovery is to recognize the problem and stop making it worse. For every new user story, the team should consider "what's the right way to ...


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 ...


24

I worked in a team where we struggled with the same problem. We found that the less time we had before integrating, the less difficult it became. I know most people teaching continuous integration talk about committing every few minutes - we probably actually committed every hour or so. We also found that just building wasn't enough. We needed a good test ...


22

What you have there is what Martin Fowler calls "flacid scrum". If you properly read all 12 Principles behind the Agile Manifesto, you will find out you fail at most of them. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Can you say you deliver truly working software? Or ...


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

Keep your branches short-lived (it sounds like you're already doing this). Let your test results speak for themselves. Don't wait for the end of the sprint. You don't even need to subscribe to TDD for this one. All you need are some tests which prove that your developers' features are working correctly. These could include Unit Tests and Integration Tests ...


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 ...


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

What you describe is - at least in my experience - a quite common emergent pattern of teams trying "to be Agile". It is open for debate if this is actually part of Agile itself or a common mis-implementation of it, is against the agile manifest/principles or an inherent consequence of it, and so on. Just from an empirical standpoint and just based on my own ...


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

Don’t shoot… I come in peace ;) I can relate to the other side of the coin as I used to be one of those Operations People. Just imagine that you(the Dev) are being pulled into Operation meeting where there is nothing for you to say or relate to and you have to sit there for a number of hours. And the only thing you can think of is you backlog of BAU ...


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" ...


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