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.
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 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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm with a pretty small startup and we started using a form of a Scrum/Agile development cycle.
In many ways I enjoy Scrum. We have relatively short sprints (2 weeks) and I like the Burn Down Chart to track the team's progress. I also like the Feature Board so I always know what I should be doing next. It feels good taking down a feature's card from the board, completing it and then putting it in the burn down pile.
However, we are now entering in our 18th Sprint release cycle and I'm starting to feel a little burnt out. It isn't that I don't like job or my co-workers, it is just that these sprints are... well, sprints. From start to finish I literally feel like I'm racing against the clock to maintain our development velocity. When we are done with the sprint we spend one day planning the next sprint's feature set and estimates and then off we go again.
For people who work in a mature Agile/Scrum development process, is this normal? Or are we missing something? Is there normally time in a Scrum enviornment that is unassigned/untracked to get done some minor things and to clear your head?
This is relatively normal and can sometimes be a complaint of our team members if projects continue for a long period of time.
The key to what we're talking about here is sustainable pace. If you and your team are able to sustain your pace over the long term, that's excellent -- you've achieve the hyperproductivity that all Scrum teams are striving for.
Alternatively, if you're finding that you overestimate how much work you can actually get done in a day, then you may need to reevaluate that during your retrospective. The amount of productive time in a day that a team chooses to recognize when doing their capacity planning for a sprint is referred to as a focus factor.
Henrik Kniberg has this to say:
The “default” focus factor I use for
new teams is usually 70%, since that
is where most of our other teams have
ended up over time.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
However, what it sounds like you're talking about is simply the nonstop momentum of sprint after sprint, not necessarily your productivity in a day. Here's some suggestions of things we have tried to deal with that:
End the sprint on a Friday morning. Have your sprint review and retrospective in the morning and let the team work on something else the rest of the day to clear their heads. Pick up with Sprint planning on Monday.
We introduced the notion of "lab days". These are entire days that the team is taken away from the project and they spend the day working on improving their own technical skills through research with each other and collaboration on specific technical topics. Most of the time they have absolutely nothing to do with the specific project and allow team members to think about lighter topics.
From Wikipedia on burnout: "burnout is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"
They might as well have an icon image of Scrum next to the definition of burnout.
If you think you can send someone onto something else for a brief diversion to fix burnout, you obviously haven't thought it through. Ever go on a vacation after being burned out and go back to work thinking, Wow! Now I'm refreshed and ready for another 6 months of this torture until I finally get a break again. Nope, what happens is you realize, Wow! My job sucks. Now I can really see how my stupid manager's micro-managing, development process is just another way of getting more out of me for less and life's too short for this... I should find something else to do or change jobs to something less stressful.
IMHO, short 2 weeks Scrum should be prohibited except in small doses, not more than 4-8 in a row. Use it as a tool for exceptional or critical things, not continually. Use common sense.
You’re getting worn out after 36 weeks of hard work; that’s not Scrum, that’s human nature! Scrum is not there to make you work harder, it’s there to help you work more consistently and with greater predictability. I often see people confusing the symptoms of normal project management with what they perceive are symptoms of agile methodologies (i.e. “the customer keeps changing requirements – it must be Scrum’s fault!”). It’s an important distinction though because without identifying the cause you can’t treat the symptoms. Personally I’d be looking at ways to reduce burnout such as stress management techniques. There’s heaps of info out there on how to succeed in a stressful environment.
The team that I am currently working on solves this problem really nicely. After three sprints we have a week in which each developer may work on what he wants. Those side projects should be linked to business value, but there is no pressure to get it done. It is a measure to allow us developers to explore new technologies, but it also provides us with a week of more relaxed, fun work.
This for sure helps me to not get burned out.
No matter what development process you're using, if the team is getting burned out something is wrong. It may be as simple as people not taking the vacation time they need, or it could be in the details of how you handle your scrums. Teams are effective over the long-term because everyone gets the rest they need along the way.
A Sprint is not a 100 yard dash; it is one (random) mile in a marathon, i.e. a pace that you can sustain indefinitely.
Is your Team conducting retrospectives at the end of each Sprint? This is the Team's opportunity to "inspect and adapt" their process? As a ScrumMaster, I regularly ask the Team to rate how the Team as an entity 'feels', and if they're having fun. We explore why or why not, and experiment with adjustments and alternatives.
In my experience, Team members enjoy (up to a limit) the 'pressure' that the Sprint timebox constrains. The key is to approach, but not exceed, that zone. As needed, calibrating that zone is a prime checkpoint in a retrospective.
As for "... time in a Scrum environment that is unassigned/untracked to get done some minor things and to clear your head", keeping the Team commitment at x% of the available capacity (points, preferably, but hours can be used if needed; in either case I've found something in the range of 60-70% seems the norm) is key to sustainability inside of a Sprint, and an occasional 'free code day' works well for outside Sprints.
One solution is to reduce the number of hours in the day spent on the sprint.
I know some people whose workdays consisted of a mere two and a half hour of sprint, with the remainder of the day focused on a variety of other activities: support, relieving technical debt, research, etc.. Their development velocity was set accordingly.
That may seem a bit extreme, but if I'm not mistaken it was a profitable company until the recent widespread economic shock hit.
You are in your 18th sprint!?
Considering 2 weeks per sprint, that means 36 weeks nonstop working on the same project. You also comment that work around 6 hours each day. That sounds like a lot!
I don't know that much about agile methodologies (although we're actually using Scrum in our current project), but there's a principle about your working hours (I mean, the amount of time you spend doing a task) should be 60%~70%. Now, doing numbers again, if your labor day is 8 hours long, and you spend 6 hours working, you're really spending around 75% of your labor time. This could be a little deviation that has finally make you have that feeling.
OTOH, I believe that if your project will take long time to be done, sprints should be larger, not 2 weeks, but not a month. Consider a downward curve on your burnout chart: Start your sprint with a regular task burn, and reduce your activity on the last 2 or 3 days before the sprint ends.
Agile is not a stone with the engraving:"work faster/stronger/better/harder", it's more like a blue sky with white clouds that read:"work nice, beautiful more productive". (a little lol at the end courtesy of daft punk + radiohead).
I fully understand what you are saying. For those of you that say "your pace is too fast," I'm not sure I agree that pace is always the problem when people get burned out by this process. Even though keeping track of all your progress IS a good thing, it can also be a stress factor itself (and not keeping track can be as well), not just because your boss/PM will be on you if they see something is not going according to plan, but for yourself. Just having this logged info is something that WILL make most people work just that little bit harder than you normally would ALL THE TIME and I'm not sure putting more time on your time estimates will fix this for everyone. I don't think a motivator (like your burn down chart) is always positive.
Some people won't feel this way, others will. There is not ONE way of work that WILL fit all. Never will be, in my opinion.
Also, if you say that these agile methods and sprints are not becoming more effective/productive, why are you using it at all? Why do you think companies want to use these methods at all? It's not because they are fun....
Effectiveness/productivity always comes at some type of price, in my opinion. It doesn't pop up from nowhere just by using the magic methods (if you get my point).
The only way for you to become more effective (work and pressure-wise) and do less work is make someone else do the work or by automating it.
In my opinion, one should always review ones processes and see what can be automated and spend time on automating your processes instead. Automation comes at the price of doing extra work instead of doing "the real work" but no matter how small the automated task you will always profit in the long run. ALWAYS! If not one day, in two. Not one month, two. Not one year, in two years. You get the idea.
However, I like the idea of having time off to work on personal projects. Most companies will never allow this though. But perhaps you can persuade your employer to get this time to automate your processes and this work could be "outside of sprint control" to allow the time you are talking about to "rest" and get energy back for a new sprint.
Those were just my 2 cents. I get a bit frightened when people say these methods aren't here to make us more effective and work harder. Of course they are! When you have no trace of what you are doing you will rest when your body tells you to. When "everything" you do is traced, you will push yourself. Or I correct myself, most people work this way, some will rest anyway.
Sustainable pace is a key tenet of agile. When doing the management (SCRUM) practices along with the engineering (XP) practices, a team can deliver sprint after sprint indefinitely. However, because one can does not mean one should.
It sounds like you need a change against the endless string of sprints you see ahead of you. A number of options can be offered. Every X number of sprints, a team member (or pair) can rotate off of a team. During your rotation, you can support the run team, take a class, focus on a set of spikes, take vacation etc.
If the team has 5 pairs, and you rotate a person off the line, A person could take an off rotation every 10th sprint (if a single person) or every 5th iteration (if a pair). Issues of budget and return on investment for your activities will need to be addressed by your leadership and or business partner. But clearly, having some time to "sharpen the saw" would bring benefit to the team thus the project. Keeping the team fresh and focused is a very good thing. But we must remember, we are getting paid and we need to bring value for the dollars we earn.
I think you are missing something, but you are not the only one. As Jim Highsmith says: “Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.”
I’d guess that is what is happening to your team. I recommend reading this Highsmith’s IMHO seminal post: Velocity is Killing Agility!
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 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
HI, I am new to the scrum methodology and looking for some help to get comfortable with the environment and wondering if there needs to be a bucket to track Developers and QA hours spent on deployments and bug fixes and retests. Seems like it could have major impact on the graph.
My team is supporting a number of legacy apps, so there's quite a bit of unplanned bug fixing that occurs during each sprint. We've adopted the following practice:
If the bug is easy/quick to fix (one liner, etc), then just fix it.
If the bug is not trivial, and not a blocker, then add it to the backlog.
If the bug is a blocker then add a task (to the current sprint) to capture the work required to fix it, and start working on it. This requires that something else be moved (from the current sprint) to the backlog to account for the new hours because your total hours available hasn't changed.
When we add new bug tasks we'll mark them differently from the planned tasks so make them easy to see during the sprint review. Sometimes unplanned work ends up being >50% of our sprint, but because we're pushing planned items to the backlog we know very early what we're not delivering this sprint that we had planned on.
This has proven to be very useful for our team in dealing with legacy apps where none of us are as familiar or confident with the systems as we'd like to be.
Bugs uncovered during the sprint, belonging to that sprint should be fixed automaticly as if the task/story wasn't done to begin with. Bugs emerging from previous sprints could be entered into a bug-backlog and prioritized just like the normal backlog.
EDIT: Just realized that by mentioning the "bug-backlog" i open up for the "multiple backlogs" which is a bad idea. A better way could be to mark the entry in the backlog with a bug flag or just accept it as any other story in the backlog.
The number of severe bugs emerging in a sprint should be minimal as everything is already tested before accepted and delivered to the project owner at the end of the sprint.
In reality it shouldn't impact the graph since you will commit to fixing a certain amount of bugs (by the choise of the PO - some bugs have lower priority than new functionality) and when bugs emerge from a sprint itself, well the task really wasn't done so it's ok to realize that and spend time fixing it.
EDIT: Realized something else - sometimes working on a scrum team won't always protect you from the reality of having to maintain other applications, support, etc. While this really sucks and makes the whole idea of being on a team with a single backlog and focus not really work, the reality is often that you need to reserve a fixed number of hours a week for support/maintain. Don't encourage this, but if this is the reality try and assign a single person (on rotation so (s)he doesn't turn sad) each week a fixed number of hours dedicated to said support role. This way, you know what to expect since velocity is relative - it will somehow seem like a smaller impact on the sprints.
The way I tend to handle this is to move bug fixing outside of the sprint. So a three week sprint might be followed by a week's bug fixing before demo/ release.
It isn't an ideal solution as no attempt is made to estimate the number of bugs that will be fixed in the bug fixing phase though. So I'm looking forward to others giving a better solution than me.
I think it's hard to estimate the effort for bug fixes before you've diagnosed the problem, and diagnosis is often the lion's share of the time spent.
If your bug volume is fairly consistent, I would just let it "come out in the wash" against velocity. This is what I usually do for production defects that impact a team's iteration goals.
If you realize mid-iteration that you're falling behind (e.g. you see a burn-up chart that's not looking like it will intersect with your scope line by end-of-iteration) due to bug issues, then you can adapt scope (drop out the lowest priority story) to accommodate the extra work.
In each sprint I have two 'tasks' - one for bugs found in the current sprint (i.e. on unshipped code), and one for issues found in anything else (any shipped release). This helps me keep track of how much time is lost (per developer) fixing bugs.
Any time logged in the latter category is regarded as waste and it's a key target for reduction. Time logged in the former is reviewed for how it can be more closely linked to the features and changes that caused it.
Don't put estimates against bugs, instead try to add that time to the estimates for unit/functional testing against the features you're working on.
Feel free to adapt any model to suit how your team works - there should be a culture of continuous improvment in any Scrum team, and the devs should be able to suggest and try out improvements as they learn Scrum.