Hot answers tagged

132

I see several fundamental management issues in your example: if a Scrum-Addicts manager signs a "hard-deadline" contract, but adds only a safety margin of 33% in a situation where "a new system is involved", that is pretty reckless. the availability of delivering at least x% of the features after one month could have been used to negotiate a contract ...


67

One of the value statements of the "Manifesto for Agile Software Development" is : Customer collaboration over contract negotiation The fact that Scrum-Addicts LLC negotiated a contract instead of establishing a collaboration with a customer makes me question their agility. One thing is clear : Agility needs to be accepted by EVERYONE. Agility is not ...


49

At the beginning of the sprint there is nothing to test yet Really? You have no requirements to validate? No discussions to have with your customer? No wire-frames to evaluate? No test plans to think about? at the end of the sprint there is typically nothing or very little left to develop/fix I have never been in that place in a project. No more work ...


33

Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too. Why is it taking a day to break things out into tasks? If you have a reasonably ...


30

Make estimating easier Break your sprint planning down. Do you need to estimate the individual tasks? I've done sprint planning two ways: Stories are estimated in story points and then tasks are estimated in hours Stories are estimated in story points and tasks simply fall under that with no estimate Of the two, I prefer the second option. I find that ...


20

The first point is that Scrum is all about optimizing the team, not each individual. If the team is productive and efficient, it doesn't matter much if someone is idle at the start or end of the task. However, on every team I've been on, there is always plenty of work. Let me address a couple of your specific concerns: At the beginning of the sprint ...


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


16

No. First off, vacation isn't a problem, it's a reality. The burn-down chart is supposed to reflect the reality of the project's progress, and if the project progressed less during one sprint compared to another due to vacation, a proper sprint burn-down chart will reflect that. Secondly, vacation (along with other administrative functions) is expected to ...


15

Bring something from the project backlog into the sprint (after discussions with scrum master and project owner). The size of the item you undertake will depend on how much time you have. If there is nothing small enough create a sub-task of a bigger task to get it started (ie do some of the preliminary work). Alternatively create some tasks that make the ...


15

Who is to blame? Managers, legal dept, accountants - take your pick... I know the example is somewhat contrived but the fact that the company could walk away without paying a dime if they weren't 100% satisfied should have rung immediate alarm bells as should mixing waterfall and agile thinking. Customers want to have their cake and eat it - they're happy ...


14

With "item", I suppose you mean "task". Planning optimism in software is as old as software itself. The good thing about scrum is that you are facing it soon and create visibility of it: this is why the teams velocity is based on past data and not future estimates. To complete a story, you also have to complete the tasks that turn out much harder than ...


13

I'm working on a project loosely following the scrum model. To make it clear: Your managers probably told you about Scrum but what you perform is not Scrum. How long does this typically take? Sprint review meeting + Sprint retrospective meeting ends current sprint. In short sprints they should take something between 30 minutes - 1 hour together. Next ...


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

After a while thinking about this, I came with the following convention: <year> CW <starting calendar week> - <ending calendar week>: <goal> (<version>) Version is optional. So you end up with something like: 2013 CW 27-28: Improved reporting and dashboards (v1.5.1) 2013 CW 29-30: Redesigned gadgets (v1.5.2) ... This syntax ...


12

What should we do if a item in scrum takes longer then expected? Assuming that by item you mean story, at the end of the sprint you typically put it back in the product backlog (and likely plan it for the next iteration). The team scores zero points for it in the current iteration. Another alternative, if the story is big enough, is to slice it vertically....


12

The most common means of tracking a sprint is to use a Burn-down Chart. Basically you total up all your estimated tasks that you've committed to for the sprint. As you complete each task, you subtract the estimated points and plot the new point. The goal is to have zero points left at the end of the sprint.


12

Is my understanding of average velocity and sprint commitments correct? Yeah, you have the gist of it. If not, what have I gotten wrong? The thing you overlooked is that story points are the things you get done. It is nigh impossible for everyone to work on stories right up to the end of the sprint. If you're doing things right, most of your developers ...


12

IT projects deal with unknowns; some of these unknowns are even unknown unknowns. What does that mean? Take for example a toy bridge for your model railroad. There are all parameters known to you: You know how big the valley is You know the material of the mountains, their height, stability etc. You know how much material you need You know from earlier "...


11

When we started practicing scrum, we kind of dropped our specialisms and individual projects, instead we started working as one team. While I am more of an expert in Unity3D and C# and we have another team member who is more skilled with Node.js (etc), we ensure that we are spreading the knowledge of the projects. One thing agile and scrum are in favour of, ...


10

First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical). But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the ...


10

The confusion is due to ambiguous language. The Sprint Backlog has two levels of detail. First, it is a list of Items (User Stories) that the Team has committed to deliver. Second, it is all the TASKS that the team intends to do in order to deliver each of those stories. So when people talk about the Sprint Backlog, they should really be clear about what ...


10

If you are doing scrum, you should have a Product Owner, no? It's his or her job to prioritize the stuff that comes along and manage the relationship with the customers. That said, the product owner should not be adding items to a sprint unless the team agrees to it and that there are items that have not been started yet and can be pushed out of the sprint ...


10

The idea behind TDD is that creating the tests is part of the development. You shouldn't really calculate it as development + unit test, the better way to view it is development = functionality + unit tests, where creating the unit tests is not a separate activity. While your developers are working on the functionality, they are also creating the unit tests. ...


10

Planning is one area of scrum where teams have a lot of flexibility. Try something new every sprint until you hit on something that works for your team. Some successful ideas I've either tried personally, or heard about from other teams: Do user story creation and prioritization without the entire team. The product owner and/or scrum master can handle a ...


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


9

When estimating, longer tasks have more room for variability. Variability means a lot of things - someone gets sick and takes a day off, someone gets pulled into meetings, someone has to support another project, you need to timeshare resources with other people or teams...the list goes on. By reducing the timeframe for a given task, you are trying to reduce ...


9

Keep your short releases in-house, until the customer is ready. Then, release to the customer on one of your four-week cycles. If possible, have the customer participate in software reviews between their release dates, so that you can keep your sprints on track.


9

Scrum exists to serve your needs, not vice versa. Do whatever makes sense to you. Monitor how to works. Adjust. Does it make sense to give this developer a vacation? Does your developer have some piece of trivial cleanup that they would like to do and didn't get to? Is there a particular story that the developer can get a head start on, and then set ...


9

During the sprint you create value. There is always some difference between what you had at start and end of sprint. Normally even in a way noticeable by the client. So just show the difference. in some cases the sprint deals with discovery or internal rearrangements that may sound subtle, still you must be able to show the difference and explain the ...


9

First off, "Who is to blame?" is the wrong question to ask. Assigning blame is fun and all, and will probably make everyone except the blamed person(s) feel relieved (in a "hey, it's not my fault, the boss said so!" sense), but it's not a productive use of your time, and can actually be counterproductive and cause a drop in employee morale. A better way to ...


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