151

You should first ask, 'who cares'? Completing sprints feels good, and in some companies results in cookies from the scrum parent. But the ultimate test is whether the company is meeting its goals. The above is facetious. If the company is succeeding while never completing the planned content of a sprint, you might as well use Kanban instead: you sort the ...


128

Am I missing something? YES! You went 18 months - or somewhere in the neighborhood of 36 sprints with retrospectives, but somehow couldn't fix it? Management didn't hold the team accountable, and then their management didn't hold them accountable for not holding the team accountable? You are missing that your company is pervasively incompetent. So, how ...


71

There's nothing wrong with working out your algorithms on paper first. Not so much for everyday coding, but for more complex algorithms, professional programmers work them out on paper or a whiteboard all the time, especially if a graphical format makes it more clear. For a student, every program is complex. If you want to get better at designing ...


61

My question is basically: when is it fair to look for the problem in the quality of the developers There isn't enough information in your post to answer that question. There's no way to know if they are failing because they are incompetent, or failing because they commit to doing more work than is reasonable. If I'm an incredibly gifted developer, on a ...


22

This answer is written from the perspective of someone who had such a performance management system put in place around an Agile team; like you, everyone on the team realized the difficulty/uselessness of year-long SMART goals applied to an Agile group, where, when fully functioning, the implementation of Agile can be considered inherently/already SMART. No,...


20

What is the reason for [their estimate of 2 days taking 8 days], is this common for programmers? It is, if: It isn't actually clear what they're supposed to do, so they take more time getting it right (and they should then say so, not guess about how long it will take) They're unfamiliar with the task at hand (then they should mention that and include ...


20

Consider the Project Manager's point of view By asking for complexity they want a number that they can compare with your next sprint to find your velocity as a team. They may also be trying to use it to add together your result with the estimates from other teams to provide an over all estimate on when all the stories will be done. The project manager is ...


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


19

As a lone developer, what can/should I do to make sure I am learning, There are books you can read. There are user-groups/meetups where you can talk with other developers. There is a code review site here where you can post code (that isn't vital/identifyable to your company) to get feedback. These are all fine, but no substitute for good practice. In ...


17

You say you "use retrospectives." But what does the team actually do in these retrospectives? Since you've gone 18 months without once addressing this aspect of your process, I'm guessing the answer is: nothing very useful. To me, the retrospective is the most important part of the process. Throw out or change anything else about scrum all you want (by ...


16

The general techniques are somewhat common-sense, the important thing to know is that they don't require much technical expertise. The starting point with planning is to identify the exact problem that needs to be solved and have a clear and unambiguous requirement. If you don't have that, your estimates will be incorrect. Having this documented in some ...


16

You can solve this problem with a free and simple solution. In our team, if we ever forget our planning poker cards we instead use our hands i.e. We clench our fists and show our estimates all at the same time. We find that this approach works very well as usually our estimates are on average at most eight points and any 13 point estimates are followed by a ...


15

Go for it! If we call what you are doing thinking and designing your solution, then it makes sense your process will be much faster than just blasting out code. People like to think (and the noisy ones like to tell us) that their way of doings is better. But everyone's ability and skill mix is different. So do what works for you. As you gain practice, you ...


14

how do you handle dependencies in sprint planning? Ideally, non-development dependencies are handled before sprint planning, so that you have a good definition of the backlog item to estimate effort against. But, if that was "just development for you" last sprint, then that was probably going to be just development for you this sprint, so you should really ...


13

In my current team we do c). The velocity should account for things the team really finished in the sprint. Something that was not delivered has no value for the customer, so we don't count any points for it, it's all or nothing. So we shift the whole unfinished story on to the next sprint and all its story points will be added to the next sprint's ...


13

The situation you describe is toxic. This sort of bargaining ignores reality and the expertise of the team, it willfully conceals information from the team and organization at large, and it inhibits the team from improving over time. If you want to city http://www.scrumguides.org/scrum-guide.html as an authority I would highlight: Only the Development ...


12

Then we first need to refactor many of things because the real needs are a little bit different You are creating a false dilemma. Real needs are almost always different than what users think/can tell you. Agile attempts to find these differences closer to when the code is written instead of at the end of a full project. Agile is NOT "we will just start ...


12

I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward. In that case, the first User Story that relies on these ...


11

Option A is a commonly recommended course of action. You do not award points for the completion of the story for the previous sprint and to move the story back into the product backlog, where it is reprioritized. You compute your velocity (and other metrics) based on the completed user stories and value-added. When you begin planning for the next sprint, you ...


11

when I make decisions based on assumptions [...] I get corrected Then don't make so many assumptions - clarify beforehand, ask! If the person you have to ask is not available all the time, prepare a list of questions. And repeat that whenever new questions arise, regularly, perhaps daily! This process happens multiple times throughout a project [...] ...


11

In addition to the other answers: Participating on programming forums like StackOverflow, Programmers.SE and CodeReview.se can also help you. You could decide to spend a percentage of your time there. Studying is part of the job of being a developer. Also, there's probably video's out there about new features in your programming language - those with ...


11

There are a couple of key points to get out of the way: Agile != lazy development Spikes and Prototypes are not interchangable ideas Nothing that you described above is prescribed by agile or scrum To your question about how to make your case, it depends on their real motivation. If they don't understand the impacts of what they are doing, you can make a ...


10

Thinking too much about this makes it seem more complicated than it is... It's actually pretty simple: Option C Incomplete stories go back into the product backlog, without the points being changed. When planning the next sprint and what can get done, the discussion should include the fact that much of the work is already accomplished. If the team decides ...


10

For these types of things, I recommend that you file a defect, issue or an enhancement request as appropriate so that it can be tracked, scheduled if need be, and not forgotten. Get your primary and most important work done before you start tackling the extra. Not only does this help ensure you hit your own deadlines, it also gives others a chance to ...


10

Interestingly, refactoring is the most efficient way I've found to understand code like this. You don't have to do it cleanly at first. You can do a quick and dirty analysis refactoring pass, then revert and do it more carefully with unit tests. The reason this works is because refactoring done properly is a series of small, almost mechanical changes, ...


9

Here is an excellent article by Joel Spolsky: http://www.joelonsoftware.com/items/2007/10/26.html It's a very simple process that basically advocates estimating how wrong your estimates are going to be by keeping track of how wrong they have been in the past. Over time you'll end up with much better guesses at the time it takes to do things. It's not an ...


9

I would call this a task. If I understand you correctly, it is meant to enable a new feature, so it is not a bug fix - otherwise everything should be called a bug. If the change made by this makes a meaningful difference to end users (independent of the main feature it is meant to support / enable), you may consider calling it a (sub)feature. All in all, ...


9

Frankly, I think that if you're asking this question, you're indeed not entirely convinced of the use of sprint planning. The point of sprint planning is to get the team into a state where they feel comfortable committing to a given set of user stories, where they feel they know enough to get started. Wether that takes one hour, or 2 of 4 or the whole day ...


9

I think Frank's and Encaita's answers pretty much covers it but there are some additional things to consider: Why use story points The aim of estimating with story points is to give the relative complexity of developing features for your application. A simple way to think about it is take a story you have in the upcoming sprint e.g. a url change. You know ...


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