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 am currently working in a team where we are doing the planning aprox halfway through the previous sprint.
We start a 2 week sprint on a Monday, and the following Tuesday (1 week later) we have a planning meeting for the following sprint to start in a weeks time. We also conduct a weekly backlog grooming meeting where we prepare stories for planning.
Is this normal? My scrum master says this is a common method and widely used.
Is there any source of information for the case of holding the planning during the previous sprint?
Does anyone have an opinion on the pros/cons of doing this?
I agree that it seems unusual, but I need some good reasons for doing it. I can't bring this up only knowing the negatives. Is there any justification for doing the planning before the end of a sprint?
Is this normal? My scrum master says this is a common method and widely used.
No. He is incorrect. One sprint ends with a sprint review meeting. Then, the next sprint begins with a sprint planning meeting. Another meeting that happens during a sprint is a Product Backlog Refinement (aka Grooming) meeting.
Is there any source of information for the case of holding the planning during the previous sprint?
There appears to be no source of such information, other than your Scrum Master.
Does anyone have an opinion on the pros/cons of doing this?
Yes. It wastes time for at least two reasons:
It takes up time, during the sprint, when other work (such as perhaps backlog refinement) could be done.
The planning that is accomplished in that meeting may need to be re-planned at the beginning of the next sprint.
...I need some pros, some good reasons for doing it. I can't bring this up only knowing the negatives.
Really, there are only negatives.
That approach is quite unusual for several reasons.
Firstly, you don't know how the remainder of the sprint will go. It is quite possible some work will be incomplete and may need to be considered for the next sprint.
Secondly, the whole idea of Scrum is to get feedback from the stakeholders at the end of sprint showcase and feed this in to planning. If you have already decided on the content of the next sprint it implies you do not care what the stakeholders say.
I coached a team recently that had been doing planning 2-3 days before the end of the sprint. They had encountered numerous problems including having to carry over unfinished work and being forced to re-plan after the showcase. After we moved the planning sessions to the beginning of the sprint these problems went away.
In order to prevent long planning meetings I would suggest doing timeboxed "Backlog refinement meetings" during the sprint. Depending on the Sprint lenght and the uncertainty of the product backlog I would schedule one short session each week, unless you are doing one week Sprints.
The actual sprint commitment still only happens in the Sprint planning meeting, which starts after the previous Sprint ends.
But having the extra "estimation and planning" meetings during the Sprint will make the life of PO easier, the backlog more clear and the planning meetings shorter. Although not part of the official Scrum I can advocate for doing "Backlog refinement meetings" during each Sprint.
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 7 years ago.
Improve this question
let me paint for you the scenario in question:
I'm working through my weekly sprint using Trello. My board:
is up-to-date. Alas! Here comes a new business-critical feature requirement (e.g. Dancing hamster animation). I'm only 2 days into my sprint! Which of these options do I do!?
drop what I'm doing, add Critical feature to sprint and start working on it immediately
drop what I'm doing and make room for new Critical feature by moving other cards (aka pieces of work) into next week's sprint. Start working on critical feature.
tell the product owner that my sprint is locked and I'll add it to my next sprint
exclaim "Hey! where's my scrum master, he's supposed to shield me from this!" (This is a joke, we are 3 developers and don't have a scrum master).
Currently we implement option 2. This way the sprint remains a manageable unit of work, with a defined release date. After the sprint has finished we (the dev team) will review the sprint and follow up with the business team to see if we can avoid this situation going forwards.
Which option "is the best" or do most people recommend? I know it depends on your implementation of agile and kanban and scrum and all that but I'm looking for the best way for us to handle sprint modifications.
Please be gentle, we're learning agile methodologies. Please don't be overly dogmatic since this approach is called "agile" - not everyone has to do it in the same way.
Many thanks!
This is going to be highly opinionated, but #2 is what I end up doing most of the time. However, it also depends on your release cycle. If you're releasing at the end of the sprint and need this in, then it takes precedence over what was already scheduled.
Scrum idealists will say #3 is the right answer. It's not the wrong answer, but it also negatively impacts your working capabilities w/ the product owner.
Scrum is a team activity. The delivery team works with the Product Owner to deliver maximum value to the organisation as effectively as possible.
If the Product Owner wishes to introduce a business-critical feature to a sprint then the delivery team will usually work together with them to make it happen. However, a number of things need to be kept in mind:
Is the newly introduced story ready to be introduced to the sprint? Are there any unknowns about the work? Is there any preperation needed before the work is started?
Will the newly introduced story significantly impact on the planning for the sprint? If it will, it may well be worth the Product Owner aborting the sprint and calling a new planning meeting. This isn't ideal, but it can and does happen (particularly with organisations new to Scrum).
The impact of the late change to requirements should be raised as a discussion at the team's retrospective. Is there anything that can be done to avoid this situation happening in the future? Perhaps the sprint length is too long to accomodate the rate of change in the organisation?
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 am working in 2 scrums as a developer, and it is difficult get anything done - I wanted to ask if other people have had the same issue and what did they do to manage their work?
It does not seem an agile way to work at all.
The problem is one of commitment. As a team you commit to your peers at the sprint planning meeting and each daily scrum what you will all accomplish together. If you have another team, that undermines that commitment naturally, it also inflates your WIP and causes task switching and the additional overhead of the ceremonies for two teams.
Why are you on both teams? The usual answers are: domain knowledge, skill set, because we only have one QA (insert any discipline there), funding/allocation, etc.
I fundamentally believe that your team will not have a reliable, predictable team until you form your teams in a way that you can commit to your team mates.
Report your situation as an impediment to the scrum master(s) and commit yourself only to the work you think you can achieve until this impediment is solved (by the scrum master(s)). It is not a contest on who commits to the most work done and then not achieving it.
I rather think this is a discipline issue. If you are following you need have scrum disciplines. What happens is when you are a shared resource, there will be switching cost and productivity loss. If you still want to follow this, you need to take actions to reduce switching cost and increase productivity.
One thing that you can defined dates where you are going to work on. Ex: first three days you are in one project and next two days your are in other project. If you define like that, then you can plan work to increase productivity and reduce switching cost.
Another thing is that reduce the participation time on stand ups and sprint planning. Make sure to prioritize your areas and discuss and then you leave those ceremonies than staying for the entire meeting. this is a responsibility of the scrum master to plan.
Working in multiple teams is possible, but each team needs to be considerate and accept they are only going to get 50% (or just under) of your time.
When planning, don't over commit, look at how many story points you can roughly achieve in a sprint and only commit to 50% of that total for each team.
Try splitting your time into Team A's work in the morning and Team B's in the afternoon. Each team will then know when you are available to them and should try (unless urgent) not to disturb you when you are not doing their work.
Have dedicated times for planning, standups and try to get the team to stick to these so you are not double booked.
The scrum master (or any elected person) for each team could also consider having a scrum of scrums where they get together and quickly discuss how things are going in the same way as a normal scrum so that they understand what pressures you are under.
However you mange this, you will get less actual work done than being in one team due to the commitments such as planning, standups, retrospectives which agile introduces.
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 are trying to implement Agile methodology in our development environment. Does a story require a start and end date OR is it purely applicable to a Sprint?
-Alan-
What do you mean by "end date"? The date you expect to finish the story (the dreaded Deadline) or the date you actually finish the story.
I'd say stories do not have a "date I expect to start/end this story" in Scrum². What you have instead is "the sprint that the team commits¹ to taking on the story". This is like an end date as you get an "all being well it will be released at the end of this sprint" but it is less finely grained as all work committed to at start of the sprint will, if all goes well, be released at the end of the sprint. You also don't get that information until the team actually commits to it.
You also have the estimated size of the rest of the backlog and the teams velocity. This can give a guide to when the story will be started. But it is a guide to a sprint, not a hard and fast date that you will pick up this story.
So what do you need the start/end date for? Once you know that you may find one of the other metrics Scrum/your flavour of Agile will provide you with the data you want. Or find that the data you want and Agile don't work together.
1) I've noticed a trend away from "committed" as it sounds rather fixed when it really means "we will try to get it done by then".
2) Scrum is only one of a ton of different Agile methodologies and while many people feel they have the One True form of scrum it would properbity be easier to get everyone to agree on the One True Emacs Bindings that the One True form of scrum. Some implementations of Agile or Scrum may have deadlines.
There are no start and end dates on stories.
Stories are bits of value that may (or may not) be implemented in your application.
In Scrum the decision to implement a story is taken at the sprint planning meeting where the story is moved into the specific sprint backlog that is being planned. Sometimes though stories are split at this point so a particular (original) story may actually only be partially implemented or implemented at different times.
So in a sense the "start" and "end" date of a story are the start and end dates of the sprint it is implemented in, with the caveats above.
Much like the others have said a user story will get its start date when you start work and the finish date will be when you are done. I think you maybe looking for an estimation on how long the story will take to complete - if that is the case then usually I put them into buckets of 1hr 4hr 8hr. If they don't fit into those categories you may need to rethink the complexity of your user story because it could be a large task that you are dealing with and require a user epic... which is just a larger story.
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
Is there a difference between Sprint and an Iteration or one can have Iterations within a Sprint or Sprint is just the terminology used instead of Iteration in Scrum? It will be helpful if someone can throw some light on this.
Suppose there are 4 sprints and you have decided the first sprint will go up to 10 days is it required that other 3 sprints should have the same length of the 1st decided sprint's length??.
All sprints are iterations but not all iterations are sprints. Iteration is a common term in iterative and incremental development (IID). Scrum is one specialized flavor of IID so it makes sense to specialize the terminology as well. It also helps brand the methodology different from other IID methodologies :)
As to the sprint length: anything goes as long as the sprint is timeboxed i.e. it is finished on the planned date and not "when it's ready". (Or alternatively, in rare occasions, the sprint is terminated prematurely to start a new sprint in case some essential boundary conditions are changed.)
It does help to have the sprints of similar durations. There's less to remember about the sprint schedule and your planning gets more accurate. I like to keep mine at 2 calendar weeks, which will resolve into 8..10 business days outside holiday seasons.
Sprint == Iteration.
The lengths can vary, but it's a bad planning precedent to let them vary too much.
Keep them consistent in duration and you will get better at planning and delivering. Everything will be measured by how many 10-day sprints it takes to finish a series of use cases.
Keep them consistent in length and you can plan your deliveries, end-user testing, etc., with more accuracy.
The point is to release on time at a consistent pace. A regular schedule makes management slightly simpler and more predictable.
The important thing about a sprint is that: within a sprint the functionality that is to be delivered is fixed.
A sprint is normally an iteration. But you can for example have a 4 week sprint, but have 4 one week "internal" iterations within that sprint.
There is a lot of discussion about the length of sprints. I think that if you do it according to the book they should all be the same length.
We have found that a short first sprint to get the development environment up and running, followed by longer basic functionality sprints, then short sprints towards the end of the project, has worked for us.
"___ is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"
No this is not the definition of scrum, it is the wikipedia excerpt on the definition of burnout.
Dont do too many short 10 days sprints. You will burnout your team eventually. Use short sprints where you really need them, and don't do too many in a row. Think long-term. A distance runner always paces themselves for the full race and does sprints in short distances only where it matters.
If you burnout your team you can toss out all them fancy scrum charts, they won't do a thing for your team's plummeting productivity.
Iteration is synonymous with sprint, sprint is just the Scrum terminology.
On the question about sprint length, the only caution I would note is that in Scrum you are using the past sprints to gain a level of predictability on your teams ability to deliver on their commitments for the sprint. They do this by developing a velocity over a number of sprints. A change in the team members or the length of the sprint are factors that will affect the velocity for a sprint, over past sprints.
Just as background, velocity is the sum of estimation points assigned to the backlog items, or stories, that were completely finished during that sprint. Most Agile proponents (Mike Cohn, Ken Schwaber and Jeff Sutherland for instance), recommend that teams use "the recent weather" to base their future estimations on how much they think they can commit to in a sprint. This means using the average from the last few sprints as the basis for an estimate in the upcoming sprint planning session.
Once again, varying the sprint length reduces your teams ability to provide that velocity statistic which the team uses for sprint planning, and the product owner uses for release planning (i.e. predicting when the project will end or what will be in the project at the end).
I recommend Mike Cohn's book on Agile Estimating and Planning to provide an overview of the way sprints, estimation and planning all can fit together.
Where I work we have 2 Sprints to an Iteration. The Iteration demo is before the business stakeholders that don't want to meet after every Sprint, but that is our interpretation of the terminology. Some places may have the terms having equally meaning, I'm just pointing out that where I work they aren't the same thing.
No, sprints can have varying lengths. Where I work we had a half a Sprint to align our Sprints with the Iterations that others in the project from another department were using.
Sprint is just the term for an iteration.
You can change the Sprint length to be anything you want, but likely you'll want to try to find an amount of time that "works well" (which may mean any number of things for your team) and end up sticking with it over time.
According to my experience
Sprint is a kind of Iteration and one can have many Iterations within a
single Sprint (e.g. one shall startover or iterate a task if it's
failed and still having extra estimated time) or across many Sprints
(such as performing ongoing tasks).
Normally, the duration for a Sprint can be one or two weeks, It
depends on the time required and the priority of tasks (which could
be defined by Product Owner or Scrum Master or the team) from the Product
Backlog.
ref: https://en.wikipedia.org/wiki/Scrum_(software_development)
Sprint as defined in pure Scrum has the duration 30 calendar days. However Iteration length could be anything as defined by the team.
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
So I have a backlog of features and we are about to get started on a sizable project. I am working on defining the structure of our sprints and I'm interested in the communities feedback.
What I'm thinking is:
One day sprint planning
Fill the backlog and figure out what each dev will go after this sprint
Three weeks of development
GO! GO! GO!
Daily stand up meeting
Check to see if anyone needs help or feels off track
Two days of sprint review
code reviews happen here, stakeholder presentations
One day sprint retrospective
what did we get done in the last sprint? how can we do better next time?
Sprints should always end on a Tuesday (to avoid too much weekend stress).
Anything else? There is obviously more to agile than this. I want to provide the team with a simple outline of how we are going to operate as we get this project started.
I'd consider experimenting with sprints that are shorter then one month.
Personally I find one-two week iterations more effective at getting effective feedback quickly. It also prevents any issues that may be causing problems at the iteration level building up to levels that become harder to manage.
Even for the 30 day sprint - two days sounds about a day to long for the sprint review... and one day sounds about 0.5 days too long for the retrospective. I've found that if you need much more than that there have been communication problems while the iterations has been going on - so you might want to look at needing long reviews as a possible red flag.
Of course that's just been my experience - of mostly developing web apps with smallish (4-12) person teams. You're experience may vary.
That said - I'd definitely give shorter sprints a try. Like integration builds - a lot of things get easier if you do them more often.
Turn off email, cell phone and instant messaging apps for core code time. 10am to 1pm, 2pm to 5pm might be good blocks for this.
Order food, drinks for team when they are in "the zone".
Cancel all other meetings for the days of, before and after the planning session and the review days.
Make sure the "stand-up" remains a STAND-up. It is very easy to slide into longer and longer meetings.
One day of sprint planning and three days at the end may be too much. Only schedule as much time as you need.
+1 to the idea of shorter iterations. Personally, four one-week iterations within a sprint have worked well. People are great at estimating near-term tasks; past that it becomes more and more guesswork.
Looks like a good approach. I second what adrianh and jedidja said about possibly shorter iterations. I like 1 weekers myself. As well as better estimation, it also keeps the idea of "working software" on a much shorter cycle.
A few questions:
Why are code reviews left until the end? Either pair program, or do your reviews as you go.
Does 3 weeks of development mean "dev, test, documentation, installers, etc" ? I.e. everything you need to be truly done?
We structure our sprints very similar to your outline except our sprint reviews are the last day of the sprint and generally on last about an hour. The sprint review is the time where you exhibit your work to the customers and any other interested parties, not the time to do code reviews. Code reviews, if you chose to do them, should be done periodically throughout the sprint. We used to have a one hour block each week where we'd go over developer nominated code, meaning we didn't waste time reviewing every LOC written.
We also end our sprints on a Tuesday and begin on a Thursday leaving Wednesday to wrap up loose ends and tackle technical debt created during the sprint.
I don't recommend postponing code reviews until after the sprint, they should be an integral part of the development process. In other words, a task is not done unless the code has been reviewed (and tested, and documented, and ...).
Its important to stay away from managing for the sake of managing. SCRUM only requires 1 meeting a day, and that's a short one. Additionally, during each sprint, the only other meetings are the Spring retrospective, and the sprint planning. This allows us to implement ROWE, or a Results Oriented Work Environment. Let your developers decide How, Where, When they will do thier development. Use your daily stand-ups to track that they are doing their work. Other than that, stand back and be amazed at thier productivity.
Ideas like "turn off cell phones, turn off IM apps, etc during coding" are all bad ideas. When you hire your team, you are hiring them with confidence that they know how to do thier job correctly. If you hired them with that understanding, why would you want to constrain thier ability to get thier job done the best way they know possible? If you're using SCRUM, then each developer will have chosen the work they feel they're able to do, your job as a Scrum-Master is to remove obstacles, not create them.
Code Reviews: Absolutely necessary. Peer reviews of code are a great teaching tool for junior developers attending meetings, and for the folks having thier code reviewed.
Design Documents: I personally feel that detailed design documents covering what the developer intends to do is very important, and I also feel they are an important part of the development process. Now, this is not specifically in-line with agile development, but I personally regularly refer back to design documents created years ago to see what the original developer was thinking when they coded their modules.