Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I work in a SCRUM team and we had a session of pokering just minutes ago.
I had (still have) an idea of 'how should I poker' but my team had another idea of it. I come today in front of you to ask if I should change the way I see pokering or is the environment (team) not 'SCRUM-enaugh'...
We had this story .. I pokered 50 storypoints (the numbers are not important, the idea is), 2 colleagues pokered 10, the rest of the team pokered an average of 25. We talked over this a bit and we decided to repoker.
As my experience has not improved during the talks, nor the requirements changed, I decided to still poker 50 on it while the rest of the team 'agreed' on a 25 storyPoints estimation.
25 remained.
My argument: after the talks, I consider my knowledge on the story is the same, the requirements are the same thus my estimation is the same.
Team argument: after the talks, we saw that there are 2 guys that know exactly what the story is about and they estimated 25 so we are going to poker all 25 because 'there would be a 25 sp effort of the team'
Should I change the way I see pokering or is the environment (team) not 'SCRUM-enaugh'... ??
Thank you guys.
The situation looks good enough to me. When people after discussion still do not converge toward same estimation, it is a common practice to take the mean (in your case about 25).
It is also common that different people in a team have different "bias": some people tend to over-estimate all stories, other tends to lower-estimate. That's why the mean is a good estimation.
Anyway, after some iterations, you and the team will have more knowledge about the difficulty of this kind of story. The estimation should become easier as all team members would be able to refer to a past experience instead of a best-guess of a complexity.
You don't have to change your estimation, if you can justify. And if you could justify, then the team is not 'SCRUM-enough'. And then the team needs to go through it's estimation procedure and check out for improvements :-)
This is what our teams call "conflict resolution". Every time we put together a team on a project, part of our team charter is to get everybody to agree to a conflict resolution model. We use this to ensure that in the case where we do not have 100% consensus, we have a model that everyone has agreed to to resolve the difference.
In your case, your model starts by having a discussion and re-estimation to attempt to get folks onto the same number. When that fails, most of your team seemed to believe that taking the mean/average/most voted as the estimation was correct. By your question, I tend to think you had not agreed with that approach.
On some of our teams, we have used a "competition" model, like rock-paper-scissors, to determine a victor. Sometimes it's always "highest wins" so that if the person who grabs the story is the person who needs more time they have the points to do it. Sometimes it's "majority rules", as seems to be the case on your team.
I would suggest to your scrum master or product owner to have the team agree on a single model that everybody agrees to so that everybody knows what they are getting into. Something like the following.
Model:
Step One: Discuss for 2 minutes and re-estimate.
Step Two: If still deadlocked, choose majority.
Step Three: If no clear majority, choose higher value.
Obviously, this probably isn't the model you'll use, but it's an example of how you can go about getting your team to agree to something that always has an outcome and still allows the basic principle of talking it out first. The most important thing is that everybody knows what the model is, and everybody agrees to it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I know this may not be exactly a coder question, but I feel it is still related to programming because I'm sure many developers have come across this before and might have some insight on how to resolve this or have advice. There is an actually programming question though.
My issue as a developer.
I work in a small company, roughly 15 people, 5 of which are developers include myself, the rest are tech support and management. Problem I'm having is, when we get a SOW (Statement of Work), our clients give us a rough description of the project they are requesting, which usually is a 1-3 page brief description, usually including a Visio document, now as a programming, I'm responsible for going over the document and relaying a time-line on how long it should take me to complete the project.
Unfortunately, there have been times, not only me, where we under-estimate the project because we didn't fully get into it till we actually developed it, which ends up slapping ourselves in the face, because my boss is upset because he is being hounded by the client, who is now upset because we missed our promised deadline.
My question is, how do you guys handle organizing basic project description when you need to give deadlines on more concept, and do you have any ideas on how to organize it.
I'm thinking of going to my boss and suggesting, instead of always pushing a estimated deadline to our clients which expect us to hit that, we should write up a detailed document that is more step-by-step (more like what to do) on how to develop the application they want, it may take a lot more time, but least if the project is moved to someone else it is laid out for them, and when I usually get back to it 4 months later, I don't have to refresh up again, I can just follow the steps I wrote.
What do you guys think? Ideas? Or better ways to handle this?
If you switch your development to using an iterative methodology (Agile, XP, Scrum, etc), then the customer will see results much earlier than any deadline you feel you have to promise - usually every 1 or 2 weeks.
The moment they see what you've developed, I can pretty much guarantee that they'll make changes to their initial requirements as they now have a visual representation of the product and it may not be quite what they were thinking of. Some of their changes might be quite radical, so best to get the feedback as early as possible.
In all the projects where i've insisted we do this, the customer was delighted - they saw the results early, could influence the project outcome, and we hit their end deadline. Unexpectedly, a whole load of features got left behind and - guess what - the customer did not mind at all as they got the top features they wanted and put the project/product straight into production as they'd had lots of time to refine it to suit their business, so they were already familiar with it.
It takes a lot of effort to get management, sales, creative, etc, to all buy-in to an iterative style, so you may need to implement a hybrid solution int he mean time, but in my experience, it is well worth it.
If a complete shift to iterative is not possible, split your project into tangible milestones and deliver on those milestones. As others have said, inflate your estimates. My previous manager doubled my estimates and the sales team doubled his too.
Inflate your project deadlines. It's something that most programmers should do (and I quote the VP of Freeverse, the company that I work at):
It is a well-known fact among people
who work in the software industry that
the last 5% of development always takes the longest.
If possible try to divide the higher level tasks as much as possible so that you can get a better approximation of how many man hours that sub-task would take.
Also, adding hidden buffers to your task execution helps in covering some of the unseen contingencies.
cheers
If you mock up (balsamiq or whatever) with your customer, you will get more details. Armed with those details and some experience, your estimates will be more accurate. And then double it and add 4 (hours,days,weeks,months)
First, unless you systematically under-estimate, your boss should not get upset. It's his job to answer to the client, and he should know that by definition, an estimate is NOT the future. Statistically, sometimes you should deliver earlier, sometimes later.
Personally, I think that the frame of "how long will it take" is not exactly the right discussion to have. Software development is a risky business, and change/surprises happen all the time. One approach which helps is to focus less on the "right" number, and more on the volatility. Look at the project, and consider the places where you are pretty clear on how long it will take (you have done it before and understand it well), and look at the places where you have uncertainty (unclear requirements, new technology), and for these, think about how bad it could go, and why. That will help you get not one number, but rather boundaries: what you think is reasonable, a worst-case scenario, maybe a best case scenario (which the client should never see :) ) - and convey that information to your boss, so that he can manage accordingly.
Additionally, this will allow you to identify the danger points of the project, and you can then prototype accordingly - look into the uncertainty points as early as possible, so that you can tighten up the timeline fast, and have early warnings for your boss and the client.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have worked on a few multi-cultural projects (programming languages are universal, social norms and mores are not) and it's always interesting to see how the team dynamic works cross culturally. I'm not talking about coding differences, I'm talking about basic ground rules for communicating cross culturally at the start of the project. Good team building exercises, using small teams vs large teams, isolating functionality to make all developers feel as if they are contributing, fostering respect, and etc.
In our increasingly multi-cultural industry, what works and what has failed?
I looked into this in some detail a few years ago and came to the following conclusions (in no particular order):
The outsourcing organisations we looked at (all Indian) had a very strong process base. I don't know if this was cultural or just the way they chose to set themselves up (possibly a bit of both) but we felt this was likely to be a real issue.
They were talking about being a five on the Carnegie Melon Maturity Model (Google it but basically that means they've defined and documented everything up to and including what happens when someone farts), we were typically running around a 1 or a 2 (roughly equating to crossing your fingers and hoping for the best).
Our process level was largely driven by our clients who didn't have any interest in signing off specifications (for good reasons and bad), wanted people who understood their business and would fill in the gaps, and wanted to change their minds three times a day. As much as many of these factors infuriated the programmers in the UK we understood that they were never going to change.
This was possibly our biggest concern - we didn't feel we could come up with a process model that would work for all three groups involved (the clients, the UK based IT team and the Indian based outsource team).
So first thing is - work out what your process is and work out whether you honestly think you can make it work for all parties involved. It's easy to say "we're going to do agile" but how are you going to get that to work when one party is 1000 miles away? Alternatively if you want to go a solid waterfall route, is that realistic given your clients?
Second, understand the ingrained cultural differences within your teams.
My experience (and I obviously generalise here) is that programmers from the US and the UK willingly (sometimes too willingly) question authority and assumptions. Ask them to do something dumb and you're likely to find yourself being told that you've asked them to do something dumb in no uncertain terms and they'll then proceed to tell you what you really want.
That's not the norm globally. Many Indian developers I've worked with don't question things in the same way. That's not to say they aren't as bright, they just apply their intelligence to delivering what you've asked for, assuming that you had a good reason for doing so.
You can make a case for either of these being good / bad (I've lost count of the number of times I've heard developers question what they're told and say how things should be despite not understanding the basics of the industry they were working in), but the important thing is that they're different and they'll clash.
So the answer is likely to be that you're going to need to feel out the teams involved and, based on that, pick out ways of working that are comfortable for both of them.
Yes, get video conferencing set up, get each time to visit the other site (it makes a big difference) and where possible get people talking even when it's not strictly needed in the early stages, but most of all make the effort to understand the groups involved and design a dynamic that works for all of them - imposition of one world view on the other won't work.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I've just come from a discussion about who is best placed to give estimates on a given piece of work.
At a detailed level I'd always say that the best estimate comes from the person who actually has to do the work as they have the full understanding and this gives them complete buy-in to the , however at a higher level of abstraction (i.e. at overall project level) I'm not so sure.
I'm reminded of chapter 5 in Peopleware which gives the results of an Australian study from 1985 - best link I could find is here.
I'm particularly interested in your focus here - are you answering as a developer, architect, prject manager or whatever?
I'm answering this as both manager (present) and developer (past).
High level estimates should come from the team/project leader, but with input from the developers. They should also be given in the form of a range - most likely to worst case with an indication of the confidence level of each.
There's no way the team lead can know everything about the project in sufficient depth so they will need some input from the developers, but the danger with this is that you get bogged down in the details too early in the process. Equally, individual developers will not have a broad enough knowledge of the project (unless it's really small) to be able to give estimates on everything.
The manager then integrates these estimates and looks for conflicts and synergies to get the "big picture" - after all that's what we're paid for.
As a developer I wouldn't trust a manager who gave estimates without checking with the developers, but equally I wouldn't trust one who just asked the developers and passed that information on without "editing" it in some way.
The person responsible for signing off of an estimate should really be the project manager. That's their niche.
I'm not saying that PMs should make up the estimates however.
I'm saying that the PMs will need to take estimates from a variety of sources--technical, business, etc--for different parts of the project. In any project there'll be large parts that aren't technical.
Anything technical should be estimated by someone technical.
But, by the same token, anything non-technical should be estimated by an appropriate expert (CPA types call these SMEs--subject matter experts). An architect could estimate the technical solution. A BA the gap analysis. A manager could do the business process implementation. And so on.
But a PM is really needed to tie all those together into a high level estimate, particularly in terms of resourcing and working out the interdependencies and the critical path.
Developers generally should make the initial estimate. The Manager should be able to add a risk factor to it depending on who implements it. (for example : If the developer implementing it has a better knowledge than the one who gave the estimate, the risk would be lower).
The developer also may not have an idea on the other development areas of the project(assuming its huge). This is where a Manager's estimate comes into picture. IF the project is small then a developer estimate is good enough.
Everyone should give an estimate to the project manager: functional analysts, test analysts and the senior developers.
It's the PM's task to make sure they are somewhat realistic and to sum them up.
The tongue-in-cheek Agile answer is: nobody should, because it will be wildly wrong anyway.
I think it depends on the piece of work. A lot of times the project manager is more than capable to estimate how long it would cost to say, add some additional data on screen, change layout, you name it.
However, there are times when things are more complicated, especially if they deeply touch the architecture of the system. In that case, the project manager should consult the developer, architect, or both for their estimate, and exactly why it takes that particular time to implement.
Moreover, I think project managers should use a developer's estimate to get to the final estimate, like schar says. They should add a percentage of overhead, test time, risk factors, etcetera.
I'm answering this as both manager (present) and developer (past).
In our company developers are always involved in making estimations. We do high-level estimates on user-stories created by a business consultant.
The business consultant communicates the user-stories to me (technical teammanager) and a developer.
We schedule an estimation meeting to discuss the user-stories and the context of the project (three people, business consultant, developer, technical manager). Within the meeting both me and the developer make notes and write down needed hours per user-story.
After the meeting the developer fills out an estimation form and we make sure we both agree on that estimation. When finished the estimation form goes back to the business consultant.
Usually a high level estimation will be given in a range from x to x times 3 days.
For example: 40 to 120 days.
Obviously we only estimate development/test/deployment time which is needed. X percentage will be added for project management and technical management, risks and overhead.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Reading the XP book, I have a condtradiction in my mind that I cant address and am wondering if you guys can help.
XP says write stories on index cards, assign those to a developer, have her estimate how long the task would take and then use pair programming to do the coding bit.
So then her and the developer she pairs with must choose to implement either his or her task. Based on that choice the work they perform is then counted toward the estimate that she made for the task. Is that estimate still valid, because it seems to be dependent on who she is working with?
The estimates have to be made with the knowledge of who is going to do the tasks.
Otherwise they make no sense.
Developer: "I can drive from Toronto to Los Angeles in 17 hours" (that's two random cities in the world and a 110% made up number, don't sue me if it isn't even possible to drive between those two cities)
Manager: "Ok, then I'm going to give you this old rusty kids bike. See you in Los Angeles in 17 hours"
Obviously that's not going to work.
So the estimates have to be made after it has been decided who's going to work on the tasks.
If not, you're going to have to build one big homogenous team, consisting of clones or something, that will all take the same amount of time as every other team member on a particular task.
Note, this is kinda the same problem of one person estimating a task, and another going is going to implement it. Unless the two are extremely familiar with each other (or at least the person estimating knows the other person 100%), you're going to get incorrect estimates.
"I estimate Bob will use 2 hours on this"
Like that's ever going to fly.
All developers in the team should be involved when estimating a story. The estimate shouldn't depend on who's going to do the work. That's not even known at estimation time. We use Planning Poker wich is both fun and gives good results.
So then her and the developer she pairs with must choose to implement either his or her task. Based on that choice the work they perform is then counted toward the estimate that she made for the task. Is that estimate still valid, because it seems to be dependent on who she is working with?
Did I read this correctly? It appears to imply that:
John estimates it will take 2 days to build a Widget
Lisa estimates it will take 7 weeks to fix a bug
John and Lisa get together, and decide to work on the bug fixing.
7 weeks occur, and even though the widget isn't started, it gets 7 weeks booked against it.
I haven't read the XP book, but surely that can't be right?
You can create dependent estimates:
If I get to work with Bob this will take 3 days, anyone else 5 days.
I'm not sure I understand the last part of the question, but when a pair get together its on the basis of one developer asking the other to pair. The developer who asks is asking that they work on his task, and they should only work on one task at a time. If they finish quickly, the pair breaks apart and goes their separate ways. If they take a long time, they may break up before the task is finished, and the original developer has to find someone else to pair with before being able to finish the task.
I didn't see a answer I could agree with, so here is a wiki describing how I now look at this issue.
Practically, the developer responsible for the task will come up with the estimate. Assuming that we can correct that estimate (based on history for that specific developer for example), we can deduce that the longest the task will take is her corrected estimate, since working in a pair will probably allow the developer to finish either on time using her own expertise or faster with the help of the person she is paired with. So in the worst case the estimate is too long, allowing for some slack.
One of my basic rules when pairing:
Never ever pair a crack with a beginner. The buddies must be comparable in skill. Otherwise, you will get low performance, frustration and trouble.
So the estimate should come out more or less realistic - no matter who did it.
My personal opinion.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
From time to time, there will be student attached to our projects, i would certainly like to assign him/her many things to do so can learn more. But alot of times we are resigned to assigning stuff like documentaiton, updating of ui mockup screens etc. As problem is that is it bit hard to trust the quality of work provided by students and another thing is that they are still young and their enthusiam may not be there.
How do we better utilize them such that they really cut down our workload and also in turns mean learning more stuff which will aid them in their future job opportunies?
I am afraid it might sound disappointing but it is not the best idea to utilise students to cut your organisational unit workload down. Probably, if your goal is cutting workload the best thing is not to take students. Read on to understand why.
Though you haven't specified the level of work-related expertise the students possess, nor did you mention the duration of their attachment, I assume from the tone of your question that their expertise is not sufficient to hit the ground running. It is also reasonable to assume that they are not staying for longer than 2-3 months.
The essential benefits your organisation can extract even given the limited timeframe are:
Notice and grab talented workers before they even get to the job market. Later in their working life they are likely not to be that easily available.
Turn every student into your organisation salesman. Let them tell everyone how good your product is, bring you in contracts in the future or make their peers envy their work experience increasing the pool of good candidates for your company.
Outsiders can help cast a fresh eye on your processes, procedures, product, expose inefficiencies etc.
Learn from them the latest stuff taught at universities.
Boost your time morale: Maslow theory, "esteem needs". Even the most junior member of your team becomes somewhat more senior, since these students have yet to achieve that position.
Cutting down workload means that you'd need to find a set of tasks which is fairly independent, does not require knowledge or skills that the students do not have and needs much of your team's time to transfer. The tasks cannot be strategically important in case they cock it up, not can it be operationally important. Hence you left with some dusty requests for management reports or research and development projects.
Chances are that R&D considered to be more desired work within your organisation and if you give exclusively to students some people feelings are going to get hurt.
How long are the students around for? When we have had students on-site for up to two weeks there was not much other then testing type work we could give them.
If the student has enthusiasm you code do some pair programming through a bug and let them write the unit tests for verifying the fix.
Even if you don't normally do pair programming, I find that with a junior dev it is sometimes productive to have him/her do pair programming with a more experienced developer, for the following reasons:
I wouldn't assign coding tasks to the junior developer alone, because his code would have to be closely reviewed by someone else anyway and quite probably rewritten or changed substantially.
On the other side, how can a junior developer learn if not by programming? So, you want him participating in some way in programming tasks.
You get some of the advantages of pair programming: the most experienced dev is less prone to make silly mistakes (even a very junior programmer can point things like 'hey, you made a typo there') and less likely to goof off checking stackoverflow.com every 10 minutes during the pair programming session.
Of course I also would rotate the junior with several seniors during the day, so they don't feel 'slowed down' or annoyed by the young guy for extended periods of time.
Why not assign one or more engineers as "sheperds" to the student and let them oversee their work or even better pair with them. The student will gain a good understanding of your project and real work and have a known fallback when in trouble and someone who can give provide direction.
The sheperd/mentor gains a fresh perspective, and the joy of teaching.