The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

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


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


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


7

The approach I have used to address these issues is to address them at the next sprint planning meeting, with choices of: Do we roll over all unfinished tasks automatically to the next iteration? Do we review each one and re-evaluate whether we still want that in the next sprint? Do we look at oustanding tasks before, 'with' (interleaved) or after new items ...


6

An incomplete feature should come out. But if this can be done without removing the code (feature flags, just removing the wiring, etc.) then that's fine -- preferable, in fact. Why? Because it limits the changes to a product which is already mostly-tested. I would recommend that, if a story is medium-to-high risk, developers should always code with its ...


6

The key of the As-a-So-That-I-want story template is simply to remind you that you need to know WHO, WHAT and most importantly WHY of your user story. You can pretty much use any format you like as long as you can capture those elements. For internal project, if all of your WHO is the same person for whatever reason, it might be silly to just keep writing ...


6

Don't Depending on your language and what files you're editing, it may not make sense for each developer to edit them on their own branch. For example, in C# I've found it's best for only one person to edit any UI designer files at a time. These are autogenerated files, and so code is sometimes moved around for no apparent reason - and this wreaks havoc on ...


5

Do what makes sense. If the code isn't going to cause any problems (say it's a function that can't be called), and/or if you are going to finish the story next sprint, then taking it out's just kinda wasting time pulling it out in order to put it back in. If, on the other hand, the code is destabilizing something else, or is user-visible in a way that ...


4

The question that comes to my mind is: Does it reall matter? If it only matters because of SCRUM-purenessness I would just go with what's most convenient. Remeber: Focusing on success is more important than following processes. I think started tasks should be finished to what extent that is possible. If tasks are really big they should of course be aborted. ...


3

Imagine you were using a physical Scrum board. The uncompleted stories would remain, the completed tasks would stay in the done column or can be cleaned (your choice), and the ones in doing would remain in the doing column as well or moved in TODO (if you re-prioritize). The only thing that will change is the Sprint number will be incremented. This is the ...


2

Another possible approach to avoid late and large merges are feature flags: you protect your changes with a (ideally dynamically) configurable flag that prevents them from becoming active before intended. This allows you to merge your changes early back into either master or your joint development branch without breaking anything. Other developers can then ...


2

It should contain enough information that, at the end of the sprint, acceptance is not going to be a problem. Sometimes a single sentence is good enough. Quite often, some team members will want more information/requirements written down to make sure nobody changes their mind and remembers all that was agreed on. Anything written down should be as ...


2

A story is "ready for sprint" when: it contains verifiable requirements and you believe it matches what the client wants. You should also try working with your owner to increase the time they can devote to working with you, and find ways that they can do some backlog grooming on their own if they can't already. The best way to get more involvement is going ...


1

When a SCRUM team works on stories from multiple projects, you should have several burn-down charts: One chart indicating the progress on the stories within the current sprint. This chart is updated daily by the team to indicate how they are progressing to the sprint-goal of that sprint. Where the stories on the chart come from should not matter for the ...


1

I think the definition of ready is pretty self explanitory, and not really worth explicitly defining. If the PO disappears until the end of the sprint (which may happen), and the team build what the story says, is there any way the Product Owner can say 'This isn't what we agreed on'? If not, it is ready. Depending on PO involvement in the sprint, and the ...


1

In my humble opinion, yes you can use user stories for non-software development projects, not just process improvement tasks. Take for instance, 3 years ago I was the best man at my friend's wedding and I used the Agile methodology and user stories for planning the wedding. All the tasks we had to complete were written as user stories with persona, intent, ...


1

Dead Code Dead code, code that is not used, should always be removed unless it's going to be used in the near future. Incomplete Stories Just because a story is incomplete doesn't mean there is not value in running what you have. If there isn't any value in it then I think it qualifies as dead code.


1

If the code that is there already has sufficient test coverage (unit tests etc), then you can keep it as it will still be being tested. If you have not got much automated testing going on, then you should probably remove it as unused code will rot, and the state of it will only be known later when it is again used. Unused, untested code is mostly noise.


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