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 9 years ago.
Improve this question
I work in a large outsourcing company based in India. I am in the US and have a team of 3 developers and we are using scrum practices and have had great success with our approach.
My problem is that our company requires us to estimate time on activities monthly whereas we work on weekly iterations. The system provides a list of 45 activities. To give an example of how granular it gets, we have activities like Coding, Coding Review, Coding Rework.
Now everyday we are supposed to enter actual time aginst these activies. And to make things worse the system for time tracking is very poorly designed and is very slow.
The rationale the management has behind this process is that they want to use this time logged to forcast future work. But the problem is that there are no processes in place to ensure that we enter correct time. So we end up putting any numbers and the end of the day.
This is affecting productivity and morale of the team and defeating the whole purpose.
What are you thoughts on Time tracking in an Agile projects?
What are you thoughts on Time tracking in an Agile projects?
100% waste: when asking you to do this, your managers are actually keeping you from working on code which is the only thing that really adds value to the product (not even to mention that the application you have to use is slow, poorly designed so this looks actually closer to 200% waste). This really sounds like outdated command and control to me. This should be handled by the ScrumMaster as an impediment.
Make sure and bring this up as and impendement to your scrum master, also bring it up in your retrospective.
Because you may have to live with it let me suggest two approaches:
Be as accurate as possible and give an estimate at the end of the day.
Write a front end to the clunky reporting system. Figure out and easy to use and time saving interface, write it, then have it feed the clunky old system.
Unless you work in a ROWE, chances are time should be recorded somewhere so that whoever is paying the salary knows where the money was spent. How useful this is and how much it can be used can be debated forever. Evidence-based Scheduling may be the idea that your management has, which has the potential to work and the potential to backfire terribly.
I'd be tempted to see if management would agree to some inbetween timeline here so that the iterations and planning align. The problem with trying to plan 3-4 weeks down the road is that what happens in the next 1-2 weeks can dramatically impact that. My suggestion would be to see if a 2-week timeline could be agreed so that almost a half-month is planned at a time. It is a bit of a compromise but assumes that whatever system the monthly data goes into would accept something biweekly. An alternative would be to do monthly iterations though that may cause some upheaval I'd imagine.
Time tracking can be useful if there is trust, honesty, and most everyone is respectful about the information. This can be asking a lot as I'd imagine many have been burned by such systems. Does management know of the slowness and poor design of the time tracking? For example, if it is taking an hour a day to log all the time and you can explain why that really is the case, there may be an opportunity to get a better system. A key point here is to know what specifically are the problems, why they are problems and what kinds of suggestions could be made as while I'd say that time should be tracked, one could use spread sheets for a relatively low-tech way that may not be great for management, but part of this is accepting trade-offs, IMO.
Sounds like the time tracking is probably a bit too granular, or too rigid in its entry. What if, instead of having you enter time for each category at the end of the day, they instead asked you to keep a log that you could fill out with what you were currently doing during the day - so you'd get something like this:
8:30am - 9:45am: Coding
9:45am - 10:00am: Coding Review
et cetera.
This is a tough one. The problem is that the time used will NOT forecast future work. That's very well documented and a dangerous trap many fall into. Velocity can help to forecast future work but it obscures the hours by design.
The problem with the approach is this: Not all hours are alike. Capturing hours turns work into "ideal" time. Future work is the estimated not by the team that is doing the work (and no 2 teams are alike), but by management that has used those hours to come up with some algorithm. Sound familiar? It's not Scrum or Agile. Management neither understands the process of Scrum nor has bought into it.
Having that confusion is not good. Clients believe you are providing something you are not, team members work under false assumptions, and management is not there to provide the support you truly need.
So, it really won't matter what you put down for hours... very likely the process will fall back into a non-agile approach which will be statistically as accurate as just making up hours and reporting them randomly. At the risk of sounding ridiculous, you might as well save your time and just make up hours.
Now, if time is used to see how much you spend doing interviews, that's easy to gauge without a tracking system.
If the time is used for billing, that's a different story. That's not Scrum-related, but a part of business process.
I was in a formal testing class, and the lecturer was trying really hard to convince one of the student to use timesheet to track time, because the entire software engineering/project management theory is based on that time sheet to do linear projection.
The problem is the reality is nonlinear (depends on the level volatility of the project)
Agile process like scrum focus on people not process, but how about people and business.
because we mentioned that tracking time was using for billing customer. the problem with tracking time is it may hurt people. for example, you estimate task and do it 10 day, next time you do the similar task and now with 10 days you cannot do it because of some unpredictable reasons, even your scrum master or PO can understand and share with your the feeling of missing the deadline(not entirely your fault)...BUT how about others behind that layer, top managers, other project managers, other developers...they may read it wrong that you had issue with your performance....so for me tracking time should be fine if we have a way to do it completely behind the developers and we then use that data to analyse the root cause and feedback for the team to learn from it. the tricky part is doing without creating bad feeling for the people which I still cannot find any workplace can do this well except rumor said that Google is the place with their fancy style.
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 5 years ago.
Improve this question
Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.
To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.
If you need more information to answer this, please feel free to ask.
Thanks.
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team
would hear about a project, it was in
the form of a requirements document
and a deadline.
Stakeholders were often reluctant
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work,
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
The deployment process was long and
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
Our sprint planning meetings were
long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on
everyone's machine (HUGE help!)
a formal arrangement for our code
repository
learning how to apply apply
abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
Reposting a related answer of mine:
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm starting up a personal project to develop some open source software. I want to use Scrum as the PM process on this (as I like the Product Backlog, prioritisation, and if I can get them, the burndowns) but it seems to me that I won't get the full value because I can't at the outset guarantee the amount of time myself and my collaborators will be able to commit to work during a given sprint.
I know there are other benefits that I will still get from using Scrum but are there variations or tricks and techniques I am unaware of which will enable me to get the value of things like burndown charts and timeboxed iterations? Or am I just being too hopeful?
TIA.
Regs, Andrew
As this is a hobby project, are you actually concerned about deadlines? How much value would it in fact give you to know how much will be done after a Sprint?
If your answers are no, you might want to look at a kanban approach as an alternative.
I think about agility in software development and come back to three aspects which provide real utility:
A known backlog of tasks to do
A regular opportunity to openly discuss the current status of tasks being addressed and hurdles to overcome
Team-managed iterations that result in a working subset of the eventual full product
In a work environment, say my 9 to 5, it is easy enough to adopt such a methodology. You've got devs who will be there at least 40 hours a week, every week and so there are few barriers to engaging in an agile practice, like Scrum.
In "after hours" settings, commitment levels of participants often vary. That's life. So you work with what you've got. If Matt is excited about the project but his schedule is busy and the number of hours he can dedicate to the project will fluctuate a bit, so what? If he's "on board" and serious about the time he is willing to invest in the project, then it is just a manner of planning your iterations accordingly.
I personally wouldn't get wrapped around the axle about this, though. In the end, Scrum or any 'agile' process that you adopt should be a means to an end, not the end itself. Particularly in an environment where conditions will differ from those in the 9-5 world, you need to be flexible in your iteration plans. You still plan your work and work you plan and engage in the regular communication and the "where are we today?" exercise to keep everyone in the loop.
The goal is solid software - if you can't get a lot of utility out of a particular aspect of Scrum, or any process, so what? You'll likely develop a hybrid process anyhow. I wouldn't get too too concerned about getting things like burndown charts and velocity and all that. I honestly think the focus needs to be more on quality software being developed and less on the artifacts that might help down the road in the next iteration or the one after that. That's my opinion though.
My advice is to use the things that work and keep it simple. Backlogs are great and the daily 'meeting' to touch base with everyone - even if this is a virtual one done by IM - is where the real value is found. Hobby or side jobs are tough things to commit to and I wish you well with it. But be open to the fact that it might not work as well as the process would at the 9 to 5.
In a by the book setting you won't use real time for calculation of the burndown chart but rather story points. After a few sprint you will see an average velocity and thus be able to generate a burndown chart and use this velocity for commiting to the sprint items.
And I strongly disagree with warrens post on the scale-down point. The main problem I see is a strongly varying velocity between two sprints, since it is only a hobby.
When the amount of time the Team is able to put in at every iteration varies too much, the velocity cannot really help to plan the Sprints since it will vary too, especially at the beginning. However, the average velocity may start to stabilize after several Sprints.
Nevertheless the burndown charts will be useful still as they show an accurate status of the current iteration.
You'll also take advantage of the estimations "calibration" Agile processes bring.
The problem with Scrum for this sort of project is more around the type of development team structure that Scrum is designed to support, in particular the colocation of the team for the daily standup meetings. Its hard to have a daily standup meeting when you aren't at the same physical location. In addition, I doubt you will have a Product Owner on your team, and you will be both the Scrum Master and a developer. On top of this you and your other developers will be working at different times and days may go by without any work being done at all. This may make coordination of the team difficult.
Every project, regardless of develoment methodology, should have a good idea of what needs to be done (the product backlog), what needs to be done shortly (the sprint backlog), and how long it will take to do these tasks so you have a reasonable estimation of how long the project will take (the project velocity and burndown). It is the other parts of Scrum that you may have problems with - not being colocated for meetings, the lack of a Product Owner, using a notice board to show the sprint status, etc.
This is not to say you can't modify the Scrum process to suit your purposes. For example:
have video conferences/Skype calls/IM meetings at prescribed times several times a week even if nothing has been done. Daily is probably too often for this type of project but maybe three times per week would work for your team.
use a web based issue management system so you can all see the product backlog, know what the sprint backlog is, and know what people are working on
have set sprint lengths (say, 3-4 weeks) so that the developers can sense the momentum and know the deadlines
understand what time is being spent on development so you can work out your project velocity and what can be acheived in the next sprint. This may be hard as available time will vary from sprint to sprint.
have retrospectives after each sprint so you can tune your development process with respect to what went well and what didn't. This would be the ideal time to meet at the same physical location if possible.
Scrum, at its essence, is mostly about effective communication so if you get that right you should be able to make a modified version of it work for you. Just remember that communication reduces in effectiveness down the list of
In person
Video conference
Skype/phone/voice calls
Instant messenger
Email
so try to use the most effective method at your disposal for your meetings.
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 8 years ago.
Improve this question
I would like to start a small part time business other than my full time programming job. Have you guys done that before? I know programmers who teach in evening schools after work. But then again, that is not business. What would you recommend to get another income stream going?
I have a full time programming day job, and I just started a small software enterprise this year.
My advice would be to start small, and make sure you have the time & energy to work on something after your day job is done. If possible, choose a business in which the code you write will be different from the code you write at work. A different language is a good start, but different types of problems would be a much better goal. If you end up working on the same thing 12 hours a day (8 at work, and 4 on the side-job), you will go absolutely crazy in less than two weeks.
As for what type of business to start, take a few things into consideration:
What kind of project would you enjoy working on?
What skills do you have, or can you learn in order to get this done?
How much time do you have available?
How much money is your time worth?
Once you have this figured out, you will know which projects make sense for you.
The only other piece of advice I can think of is to specialize. If you are a one-man operation, you can't compete with Microsoft. Choose a market in which you offer something really good to a small group of people. These little niche markets are the best place for small software companies to thrive.
Good luck and have fun!
I'm assuming you mean consulting when you say 'small business'. Network with people you know in real life. Communication skills are king. Find out exactly what your client needs and deliver promptly. Never promise something you can't deliver, it'll reflect poorly on you. Outline all of the requirements of the project and start drawing mocks/specs on a sheet of paper with your client. Outline their budget and see if their requirements are feasible for their budget. If you're developing software for a mid-sized business, talk to the staff who'll be using your product as an end user. If they currently have a solution, ask them what they don't like about it in terms of features and usability. See how it can be improved.
Be as genuinely helpful and knowledgeable as you can. If the project is out of your scope, lead them to someone who can help. You might not land that gig, but they'll probably tell three or four of their friends about you who might come back a year or two from now.
One relatively untapped market I've found is locating people who've recently outsourced. Not to make any generalizations but the "outsourcing boom" produced a bunch of sub-par software, leaving tons of code needing to be salvaged. I've found a bit of business by finding people with half-finished software and re-writing their code into something workable.
I would recommend having some sort of business plan. Don't just start writing some application or creating some web site and think it will sell. Do some research on the actual market for your product.
Also, having done it before, I would suggest having at least 1 other partner in the business. Doing it all yourself quickly becomes a waste of effort. You can do it, but it sure is a heck of a lot easier if you have someone to help with ideas, programming, accounting, web design, etc.
Also, think hard about whether you really want another job outside of your current job. I don't know what your life is like outside of your day job, but having another job (particularly one that requires daily attention like a website that has to be constantly updated) can be a real drain on your life.
If you do come up with a business plan and start a business, make it something you thoroughly enjoy! It can be very rewarding if you do.
I don't know why you reject teaching "out of hand". After working in industry for 10 years, I started teaching "Adult Education" night courses at a community college. I found it an excellent revenue stream that did not conflict with my day job (IT consulting). It was also and excellent way to remain "fresh" in my chosen languages (originally C).
Teaching keeps you on your toes, and lets you meet lots of interesting people (teachers and students) in a very fun atmosphere.
Also, when you are ready to seek another career down the road, teaching is an excellent choice. Teaching is also remarkably insulated from economic turmoil, as downturns often send people into training as a way forward.
Plus - you are giving something back.
Cheers,
-Richard
I did some work on an opensource project (DotNetNuke) as a developer and made some good contacts through that and became a consultant doing DNN work for various clients.
You obvisouly have to make the investment to learn whatever the OSS project is that you're working on, but on the other hand, there's a good chance you could carve out a pretty nice niche for yourself.
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 have had a few development managers who don't seem to understand or appreciate the difficulties of software design and implementation.
Such managers believe that processes and methodologies completely solve the problem and I have a tough time explaining to them that it is not so and that you cannot read a book on the latest process fad and hope to get results by applying them as is.
The latest frustration I have is to convince my manager to
(a) Give me requirements not piece-meal but a larger set as far as possible.
(b) Give my team lead time to think about how to design, thrash out a few alternatives, work out an implementation sketch, to plan out the tasks etc.
The frustrations are compounded because of Agile methodology and the interpretation of it that says not to do up-front design (as against BIG up-front design in Waterfall), product owner can change requirements at any time and so son.
So far I haven't had much success and have to put up with the resulting frustrations.
Can you give me some arguments that can convince such managers?
EDIT-1:
Retrospectives are done, though not always at the end of every sprint, and the problems are brought up. But as I mentioned, my manager doesn't appreciate the need for design lead time and the frustrations with piece-meal requirements.
EDIT-2
I don't have a problem with changing requirements. I understand that it will be so, but imagine this: You want a small feature to begin with and then you keep adding more around it. After a few iterations, the design cannot handle it anymore and a redesign (not refactoring) is required. This could have been solved better with an upfront design in the first place, had the related features been investigated together. Its not BDUF, its the natural way of doing it (what I call software engineering common sense).
My manager doesn't understand why I ask for time to redesign (a few times I just call it refactoring so that it fits the Agile way of doing it, but it really is redesign) and not developing and demoing new features.
Every time requirements are changed (or increased) so should
the estimate to complete and,
the assessment of risk
Start giving updated estimates (even if you have to guess) and lists of risks every time you get an updated or new requirement. This will help your manager make the connection.
Try to do this in a spirit of helpfulness--"for planning purposes"--so that you aren't perceived as obstructive or lacking "can-do attitude." Remember that estimates can (in theory) come down, and risks can be reduced.
Business requirements are going to change no matter where you work. It's not your fault, it's not your boss's fault, it's not anybody's fault. The entire point of taking the requirements on piecemeal is to encourage you to think about the problem at hand, not some other problem that you might or might not need to solve. It's quite liberating once you get into the rhythm of it.
Think of upfront design as premature optimization. You may not need it, and even if you know you need it, you'll know more about your design two weeks from now than you know about it today. It'll help you solve your engineering problem with the best possible knowledge about the state of your code.
That having been said, edg is absolutely right. When you add more requirements, the estimate changes. This isn't the fault of the developers or anyone else; more work means more work no matter how you square it. If your boss doesn't realize that adding requirements will result in a larger estimate for the project you need to explain to him that Agile isn't a magic bullet that allows you to add more features without paying anything for them.
Agile Simple Design doesn't mean don't do ANY design/architecture up front.
It means do the minimal design up front, so that you will not pay a horrible price for reasonable change requests.
Scott Ambler talks about Change Cases - http://www.agilemodeling.com/artifacts/changeCase.htm
James Coplien talks about Agile Architecture - http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
http://blog.jaoo.dk/2009/03/04/handling-architecture-in-the-agile-world/
The art/craft in all of this is in how to slice the architecture in a way that allows:
relatively fast convergence on overall architecture/infrastructure - on the order of days per months of estimated development time.
developing "just enough" architecture/infrastructure per each feature/requirement
doing the right balance of preparations for the future compared to focus on the features of today.
Its important that your Product Owner is aware of all of this balancing act as well, and you work collaboratively. He should understand that if you disregard all thinking for the future, each change will be very costly. There is a price to be paid for flexibility.
Its btw very similar to investment in QA and test automation. You pay something now, that will pay off only after X times you test the code. if the code never changes it was a waste of effort. but everyone knows that most code changes...
Buy your manager this book. That's what I did, and it worked great :)
First of all this issue seems quite sensitive, so all I wrote below is just my personal opinion, and not necessarily a wise thing to do.
In my opinion you cannot make software if you do not know what problem it should solve. If requirements come in small parts that are too small to oversee the problem, then I would just fire questions about the parts that seem to be missing. Like: "okay so the software should do X, but does that also mean Y or otherwise maybe Z? Because if it is Y then ... but if it is Z then ..." Of course if the manager is in the middle of extracting the requirements then he cannot answer, but at least he knows that there are still open issues that influence development.
About no lead time for design: design and development are an iterative process that could go hand in hand. It is just how you name the thing. If the manager wants to see some code at the end of the day, okay then I would just use the first half of the day to design and the second half of the day to make some code based on that design. If the manager does not want to see the design, fine with me then I'll just show the code.
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
We have been using Scrum for around 9 months and it has largely been successful. However our burndown charts rarely look like the 'model' charts, instead resembling more of a terrifying rollercoaster ride with some vomit inducing climbs and drops.
To try and combat this we are spending more time before the sprint prototyping and designing but we still seem to discover much more work during the sprint than initially thought. Note: By this I mean the work required to meet the backlog is more involved than first thought rather than we have identified new items for the backlog.
Is this a common problem with Scrum and does anyone have any tips to help smooth the ride?
I should point out that most of our development work is not greenfield, so we are maintaining functionality in an existing large and complex application. Is scrum less suited to this type of development simply because you don't know what problems the existing code is going to throw up?
Just how much time should we be spending before the sprint starts working out the detail of the development?
UPDATE: We are having more success and a smoother ride now. This is largely because we have taken a more pessimistic view when estimating which is giving us more breathing space to deal with things when they dont go to plan. You could say its allowing us to be more 'agile'. We are also trying to change the perception that the burn down chart is some kind of schedule rather than an indication of scope v resources.
Some tips on smoothing things out.
1) As others have said - try and break down the tasks into smaller chunks. The more obvious way of doing this is to try and break down the technical tasks in greater detail. Where possible I'd encourage you to talk to the product owner and see if you can reduce scope or "thin" the story instead. I find the latter more effective. Juggling priorities and estimates is easier if both team and product owner understand what's being discussed.
My general rule of thumb is any estimate bigger than half an ideal day is probably wrong :-)
2) Try doing shorter sprints. If you're doing one month sprints - try two weeks. If you're doing two weeks - try one.
It acts a limiter on story size - encouraging the product owner and the team to work on smaller stories that are easier to estimate accurately
You get feedback more often about your estimates - and it's easier to see the connections between the decisions you made at the start of the sprint and what actually happened
Everything gets better with practice :-)
3) Use the stand ups and retrospectives to look a bit more at the reasons for the ups and downs. Is it when you spend time with particular areas of the code base? Is it caused by folk misunderstanding the product owner? Random emergencies that take development time away from the team? Once you have more of an understanding where ups and downs are coming from you can often address those problems specifically. Again - shorter sprints can help make this more obvious.
4) Believe your history. You probably know this one... but I'll say it anyway :-) If fiddling with that ghastly legacy Foo package took 3 x longer than you thought it would last sprint - then it will also take 3 x as long as you think the next sprint. No matter how much more effective you think you'll be this time ;-) Trust the history and use things like Yesterday's Weather to guide your estimates in the next spring.
Hope this helps!
I am happy to hear that scrum has been largely successful for you - that is more important than having the sprint burndown chart look ideal. The sprint burndown is just a tool for the team to help it know if it is on track for the sprint goals. if the team has been meeting the sprint goals, I would not worry too much that the chart looks like a roller coaster. A few suggestions
During the sprint retrospective ask the team where the additional work is coming from
Extra work can come from not having good acceptance tests early in the sprint
Extra work can come from not having a well groomed backlog. A good rule of thumb is to spend at least 5% of the team's time thinking about the next sprint's stories ahead of time.
Monitor work in progress - is the team doing too much in parallel?
During sprint planning - how does the team feel about the breakdown of tasks that make up the stories?
If you have not been meeting sprint goals - use the established team velocity to take on less during the next sprint. You have to get good at walking before you can run.
In my experience, Scrum is definitely geared more towards new development than it is towards maintenance. New development is much more predictable than maintaining an old, large code base.
With that said, one possible problem is that you're not breaking up the tasks into small enough chunks. A common problem people have with software planning in general is that they think "oh, this task should take me 2 days" without really thinking about what goes into doing that task. Often, you'll find that if you sit down and think about it that task consists of doing A, B, C, and D and winds up being more than 2 days of work.
As others have said, I would expect a burndown to be up and down. Stuff happens! You should use the "up and down" bits as fodder for your retrospectives.
Make sure everyone is clear on what "being done" means, and use that joint understanding to help drive your planning sessions. Often having a list of what constitutes done available will (a) help you remember things you might forget and (b) will likely trigger more ideas for tasks that would otherwise surface later on.
One other point to think about - if you are working month on month with an unpredictable codebase, I would still expect your velocity to normalise out to a reasonably steady rate. Just track your success against your planned work and only use completed items as a maximum when planning. Then focus on your unplanned tasks and see if there are any patterns that suggest there are things you can do differently to include those things in the planned work.
I have had similar issues. My previous team (on it for over a year) was large and we maintained a very large, rapidly changing codebase for series of initial product launches. Our burndowns were shameful looking, but it was the best we could ever do.
One thing that may help (make your graph look better) is stick to the number of hours/points committed to constant. If you have underestimated a task, and have to double hours, pull something out of the sprint. If you pull in a new task, it's obviously of higher priority than something your team committed to so pull that other thing out.
We tried the breaking up the task into many tasks in and before planning, and that never seemed to help. In fact, it just gave us more damn tickets to keep track of during the sprint. Requirements started migrating to the tickets and (not surprisingly) got lost in all the shuffle.
On my new team we took a pretty radical approach and started creating big tickets (some over a week long) that say things like "implement v1.2 features in ProjectX." The requirements/feature lists for ProjectX (version 1.2 included) are kept on a wiki so the ticket is very clean and only tracks the work performed. This has helped us a lot - we have way fewer tickets to keep track of, and have been able to finish all our sprints even though we keep getting pulled off our sprint tasks to help other teams or put out fires.
We continue to push items out of the sprint if (and only if) we are forced (by the man) to bring in new items.
Another simple tip that helped us: add "total hours in sprint" to your burndown. This should be the sum of all estimates. Working on keeping this line flat may help, and increases visibility of the problems your team may be facing (assuming that won't get you demoted...)
-ab
I had similar problems in my burndown as well. I "fixed" it by refining what was included in the burndown.
SiKeep commented:
Its progress against the backlog
selected for that sprint, which may or
may not end up as a release.
Since you selected certain things for the sprint and that's what is on the burndown, I don't know that all the "new work" should appear in the burndown. I would see it going onto the backlog (not affecting the burndown), unless it's important enough to move into your current sprint (which would then show up as an upward trend in the burndown).
That said, minor up's and down's are normal, if the trendline basically follows your expected velocity. I would be concerned about the roller-coaster trend you're mentioning. However, the idea of isolating the burndown by only adding high priority items to the current sprint may help dampen these up and downs on your burndown.
As others have said, the planning before the sprint starts should be short...(no more than 4 hours).
We are using a 'time-boxed' task for unplanned tasks. Whenever high-priority work is coming, or sudden bugs pop up, we can use time of the time-box (but, we can never go under zero).
This method has the additional advantage that we can easily track which tasks were unforeseen, and keep those things into account during our next sprint planning.
You can integrate the new work at the sprint's start date, to have a great looking Burndown chart.
You can tag with a specific marker the additional work and evaluate at the sprint's end why you haven't be able to identify those tasks before.
We are now using a burn UP chart. Instead of just charting the amount of work left we chart two things: the amount of work completed and the total amount of work (ie. completed + outstanding).
This gives you two lines on the graph that should meet when all the work is done. It also has a big advantage in that it clearly shows when progress is slow because more work has been added.
If you like, the PO 'owns' one line (the total work) and the developers/testers 'own' the other line (work done).
The PO's line will go up and down as they add/remove work.
The dev/tester line will only go up as they complete work.
Article Is it your burn down chart? explains what given status in burn down chart means. It also provides suggestions what to do with that.
Some examples described in the article:
This is as it should be. If your burndown chart looks like the model chart, you're in trouble. The chart will help to see if you will be able to make you commitment and finish all the stories.
Discovering stories during the sprint will always happen. Ideally you would be able to design and find out the tasks up front but if they worked why would a big upfront design not work?
To answer you last question, the sprint planning should take at most four hours.