24

According to Mike Cohn It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. Accordingly to Scrum.org: The Scrum Goal is the creation of productive and creative ...


19

If you reduce a team from 7 to 4, especially if the reason is something outside the team, the best course of action is probably to treat this as a completely new team. People will need to change into new roles, find a new way of working together, cover fresh weaknesses caused by those leaving, find out who is in charge of what, and all the other problems ...


18

In situations like this two important rules are in conflict: don't lie to the client don't look bad in the eye of the client Based on my experience, clients appreciate the outcome of the first rule, so if you are honest and tell them about the background of the issues, they'll most probably understand them (of course, there are client, who will try to use ...


18

I'm a bit unclear how you are managing the management/support requests. Actually, I'm unclear whether you are managing them at all. You need to manage these requests, to protect your developers. Software developers can only be productive if they have extensive time "in the zone". Interruptions are the number-one thing that can kill developer productivity ...


16

You have three factors: Money Time Requirements If money and time are fixed and requirements can change then you would go after SCRUM. If requirements are fixed then you would go after waterfall.


15

Value Judgements vs. Flow Analysis Considering a self-organized team where no individual work is ever reported, how do you spot the lazy team member? This is the wrong way to ask the question, but it's understandable since people are social animals. The question is being asked through a social filter that imputes motives rather than analyzing the process ...


15

They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles. Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA. Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it ...


14

TL;DR A Sprint enshrines your empirical process by providing a maximum delivery cadence It increases communication and alignment It adds some predictability to the unpredictable nature of software by evening the batch sizes. A Sprint is a container for planning! While the Scrum Guide says that you must deliver working software at least every 30 days there ...


13

I won't say that it is all about communication, but I think a large portion of the problem you see can be contributed to communications that could be improved. I work in the same field, and I've seen this behavior from many clients in different industries. What took me a long time to understand was that the way I initially present estimates can have a huge ...


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


12

I support Zsolt approach, adding one suggestion when planning the way to deliver this information to the users: Before the fix: What caused (a misconfiguration on the application, a typo?) Why it was caused (a last minute requirement change?) why it wasn't noticed (lack of proper testing?) After the fix: Is there any potential similar problem somewhere ...


12

Stories are about concrete aims you want to achieve with your product. Of course, refactoring may well be required by concrete aims! There is really no specific way of handling large refactorings in agile on purpose. Let me give you two examples of large refactorings; one is perfectly fine, the other isn't: Change an old and broken data access library and ...


12

I would hope that by now you would have frozen scope as you have cited new requirements entering at the testing stage as a problem. That has to stop otherwise you are in an endless cycle. Once you have stopped the scope creep there are a number of areas you need to look at. But the one that leaps out at me is System Testing. If the users are finding issues ...


12

checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry? The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster. HasaniK and Jakub have already identified some very valid ...


12

Use spike to reduce the risk of a story or increase the reliability of an estimate Spike is a term that comes from the Extreme Programming (XP) practice. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate. The duration and objective(s) of a spike should be agreed between the Product Owner (PO) and ...


12

Directly and honestly. By the way, I think, this is a sales and negotiation question: As far as I understood, you would like to support your customer and maybe earn some money. You would like to do both by predicting the future and you are (for whatever reason, time in your situation) not able to prove your prediction. What is the worst case outcome? ...


12

The software project, already completed (and even then your historical data might be off by more than 10% depending on how you tracked it). Note: this is not a joke. See https://en.wikipedia.org/wiki/Cone_of_Uncertainty


12

Is it the responsibility of the Scrum master to intervene and interrupt a team member when he/she starts telling about points beyond those 3 that I mentioned? Technically speaking, no. The purpose of the Daily Scrum is to facilitate coordination between the the Team. It's not for the Team to call off those three points by rote. Many Teams don't use the '...


11

The Problems Reading between the lines a bit, it would seem that you have a few related issues. Your "team" is too large to be truly agile. You may want to consider splitting up into cross-functional tiger teams with a focus rather than a multi-project, matrixed organization. The purpose of your stand-up hasn't really been defined. Truly agile stand-ups ...


11

Use swimlanes on your board (or different coloured cards) to indicate the type of work. One team I worked with divided their board horizontally into two parts - the top for new product development work, the bottom for support/maintenance. Each steam had a separately prioritised backlog that the teams would pull work from when ready. This meant we always ...


11

The art of giving a SWAG estimate I have worked with many developers and development managers who are very reluctant to give an estimate with such limited information and limited time. They have been bitten too many times in the past. The main reason is even if the people asking for such an estimation understand the risks and give an assurance that it will ...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


10

option 1: it might work if you make these standups extremely quick and efficient (15 min is the maximum, standup could be much shorter) option 2: sounds like a disaster to me; having so many people and projects, it would be impossible to process it all in a meaningful way and still keep it under 15 minutes; you might end up with long boring "standups" (I've ...


10

TL; DR The author's leading premise is that cost containment is more important for Project A than for Project B. This is almost axiomatic if you do the math. Purpose of Project Controls Project controls are the processes and procedures used to keep a project within acceptable variance of the project's goals, especially in the area of projected cost vs. ...


10

It's a bit unclear if you're asking about estimation or about prioritization. I think lots of answers here tackle the prioritization aspect, so I won't go into that. If you're asking how to estimate your efforts, given that much of them end up being unplanned work, then there are a bunch of things you can do, but a complete solution is probably impossible ...


10

Kanban certifications are definitely not as well established as Scrum training/ certifications. But they certainly are available. The Lean Kanban University, with active involvement of/ direction by 'Kanban Method for Software' pioneer David J Anderson, has been issuing 2 kinds of certifications - AKT - Accredited Kanban Trainer - and KCP - Kanban Coaching ...


10

The short answer is never give a fixed time estimate, always give a range. And then clearly document this in emails or the project plan (writing). Long Answer: Fifty some off years of software development has proven fairly conclusively that estimating an entire project, before any work is done, has a success rate of around 20% or less (based on 80% of IT ...


10

In Software Estimation: Demystifying the Black Art, Steve McConnell presents a table that is adapted and extended from Measures for Excellence: Reliable Software On Time, Within Budget, Industrial Strength Software, and Five Core Metrics: The Intelligence Behind Successful Software Management for line of code per staff-month for different kinds of software. ...


10

This issue is not just limited to developers or agile or even in the IT industry. This cuts across all industries and all types of roles. Providing estimates is about trying to predict the future as accurately and precisely as we can and the inconvenient truth is we have no ability to predict the future with any real degree of accuracy or precision. ...


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