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?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are supposed to follow agile approach in my team.We have a Scrum master, Product owner, proxy product owner and team of devs, I am a dev.
During Poker, we need to make estimations on developpement tasks. From what I know about Agile, only devs can give estimations, in our case, Scrum master and Product owner want us to follow their estimations (they have some pression with clients) so when we estimate a task to 5 days, they do not like it, even if we have explainations why 5. And in general (99% of time) they ask re-estimation and kind of "force" us to change our estimation to 2.
The worst part is that they even do not know what they are talking about, sometimes we even have half of specifications !
My question is : According to Agile, is it true that Dev tasks estimation are done only by devs, right ?
You are right. The scrum master's role is there to facilitate the meeting, not take part in the meeting by estimating. You are correct. Estimation is only done by the dev team.
Instead of arguing with agile principles I would do a more constructive way to approach this by writing down two estimates: the dev team's estimation and the other estimation by the scrum master and product owner and when the ticket is done look at how much time it actually took. There can be learnings in there for the dev team as well, but much more learning for your scrum master and the product owner.
Sounds like a lot of pressure.
According to Scrum the final estimate is made by people who do the work:
The Development Team is responsible for all estimates. The Product
Owner may influence the Development Team by helping it understand and
select trade-offs, but the people who will perform the work make the
final estimate.
https://www.scrumguides.org/scrum-guide.html#events-planning
Maybe point your Scrum Master to the Scrum guide ;-)
The nice thing of work is it takes the amount of time it takes, doesn't really matter if it is a 2 or a 5. If they influence all the work the same you probably will have a stable velocity. Just don't take days estimates as how many days the work will take, suggested is to estimate in relative sizes, not days.
My question is : According to Agile, is it true that Dev tasks estimation are done only by devs, right ?
If you go to the literature of classic scrum the scrum planning meeting is cleft in half (by a mighty sword).
During first half the product owner presents backlog items for the team which are candidates for the upcoming sprint. The backlog items already have estimates on them (in story points) produced by the whole team (not only the product owner) during the refinement/backlog grooming meeting. The team decides on how much work to commit to by looking at velocity from previous sprints and by consulting their gut feeling.
During the second half of the of the meeting the team breaks down the backlog items into tasks and, when appropriate, sets estimation of time of respective task.
If this is a good process or not is very context specific, so I leave it to you to decide...
The purpose of estimation is to get a good prognoses of scoop for future releases. It's a tool for the product owner when prioritizing and for managing expectation towards the stakeholders. If your PO thinks he/she can get more features by manipulating the estimates, they are up for a surprise down the line.
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
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.
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 work within an agile team.
We have a released product and we are still working towards a future release.
Every sprint we receive anywhere from 0 to 5 tickets to fix bugs in the released product.
Our team is composed of software engineers (to handle new development) and maintenance software engineers ( to handle tickets).
My question is how do you account for the maintenance hours during sprint planning.
Currently we have a story called maintenance buffer where we allocate some hours to solve tickets. And we sort of use it as a buffer, so in sprints where we receive no tickets we use the hours in the buffer for development work.
I feel this is not a good agile way to do things, any suggestion?
The approach you have mentioned is also covered by Mike Cohn in Should Story Points Be Assigned to the Agile Defect Story?, where he writes:
Sometimes teams write a user story for this activity such as: “As a
user, I want at least 15 bugs fixed” or, “As a user, I want you to
spend about 50 hours this sprint fixing bugs so that the application
becomes gradually more high quality.” Even a team that doesn't
explicitly write such a user story will usually include a row on its
taskboard to make the agile defects and bug fixing visible, and to
track it.
You currently have a story called maintenance buffer where you allocate some hours to solve tickets which is something similar to what is stated in Mike Cohn's article where he recommends to assign points to bug fixing the agile defects.
There could be other options too, like
Setting some time for bug-fixing in each sprint. It could be a set time of the day/week when every team member deals with bugs.
Including each bug in the same sprint backlog by considering them as a partially implemented feature. This is discussed by Mark Summer in Managing Bugs in Scrum.
What to do in case of emergencies / hotfixes?
You need to assess the criticality and the effort required to fix that urgent bug. It is up to the Product Owner to decide if the team drops everything and starts working on the hotfix. Reason being that the customer always comes first and if the delivered product is not providing the expected value then there is no use of adding more features to an incomplete product. No framework / methodology stops you from handling exceptional cases or dictates you to ignore critical issues. So the current sprint can be cancelled or if the hotfix can be handled by one (or some) members of the team then a feature or bug, from the current sprint, can be swapped with the urgent bugfix.
In words of Geoff Watts from Production Support and Scrum:
If the issue is a true emergency, the Product Owner should have the
authority to play the “emergency card,” as long as he is aware of the
costs of doing so— not completing the items we planned to and,
potentially, jeopardizing the sprint goal.
The Product Owner can exercise any of the 3 options:
Add the urgent defect to the backlog because he/she has decided that the current sprint goal has higher priority
Add the urgent defect to the current sprint because it is critical enough which could even jeopardize the sprint goal
Cancel the current sprint, do the hotfix, and then start a new sprint after that
In brief, I'd raise bug(s) as a Product Backlog Item (PBI) and prioritise them against other PBI's in the Product Backlog. This way, you can always be sure that the most important things are done first.
Part of the unwritten contract of Scrum is that the business agrees not to interrupt the Development Team. This is partly how they can improve performance.
If you get a hot/urgent ticket that CANNOT wait for the duration of a Sprint, you need to convince the Product Owner who would then negotiate with the Development Team for the best way to introduce the hot item.
However, this would need to be an exception, rather than the rule. If, as you imply, you get a lot of bugs to fix, I'd be tempted to run the maintenance / defect fixing with a separate team using KanBan, rather than Scrum.
I agree with you that this is not a good agile way to do things! The question to ask is - is your real objective to plan for maintenance hours or to ensure that your team is optimally utilized working on both user stories and defects while turning out quality code on a continuous basis, including defect fixes?
I would go one step further from what Derek has suggested - and use Kanban AND Scrum together - Scrumban is increasingly catching on! Since you have said you may have 0 to 5 defects in any sprint, clearly your 'failure demand' is variable and so is the need for your 'maintenance engineers' capacity. What do they do when there are 0 or 1 or 2 defects? I presume they also contribute to the 'value demand' - new user stories.
This is where Kanban shines. While the actual design of your Kanban board will need to be analyzed by your team, you can potentially start with a simple 2 swim-lane board that mirrors your current process for doing your work. A simple example is shown below -
Here, you have all your engineers available for working in either lanes. As work flows in, depending on who is free to take it up - and CAN take it up - they pull work in and work on it. You still batch things for the sprint at Staging - and deploy the batch at one go.
Alternately, you might have completely separate lanes for User Stories and Defects -
Here again, all your engineers work on items in both lanes. However, you have the flexibility to deploy defect fixes as soon as they are fixed and accepted by the customer (if applicable). With your value demand, you continue to follow the same process as you are now and deploy when each sprint is done.
The advantages of either of these approaches are -
You get a bigger pool of people to work on either situation.
You potentially get faster response times, better SLA performance, on defects.
You get a happier team where everyone gets to work on new stuff. Most engineers don't want to be 'maintenance' guys :-)
Of course, this is just based on basic analysis. If you are not familiar with Kanban or Scrumban, you should read books by David Anderson (Kanban) and papers by Corey Ladas (Scrumban) and several others like Yuval Yeret, Jim Benson, Masa Maeda and prepare yourself better. You can also connect with us at www.swiftkanban.com and we can certainly help as well.
Hope this helps!
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
What do you defines as an impediment? I know that Scrum say that and impediment is something that stop the team from performing the best it can. So basically it can be everything? But where goes the magical line where it becomes and internal improvement?
For example. We want to have more realistic test data in our databases, is that internal improvement or impediment? We as a team could try to solve it in the sprint along with the other stories directly, or we could say that it's an internal improvement that needs to be a story and go into the product backlog.
As I see it we have three options:
1. Handle all internal improvements as stories in the backlog and make the PO prioritize them.
2. Work with them along regular stories in the sprint.
3. Big things goes in as stories and small stuffs we can do directly in the sprint without it effecting the velocity much.
How do you handle this? We need tips and ideas on how we can do this :)
What is an Impediment
An impediment is anything holding the team back. It's a very wide open category that can include things like:
physical hardware limitations
missing or poor tools
personal conflicts
missing skills on the team
missing personal skills
lack of influence or authority
illness
missing knowledge
We often focus on the obvious: tools and authority, but more often it's the intangible that holds a team back. Things like team cohesiveness, knowledge, and experience.
More realistic test data
Don't get caught up categorizing the improvement as internal vs impediment. Our goal is to embed improvement into the natural delivery process. For that reason, my first inclination would be to say all impediments and improvements should be done in the context of delivering. You want improvement to be reflected in the ability to deliver. We want our outcomes to reflect reality. Sometimes improvement efforts mean we temporarily lower velocity in the name of future increases. Sometimes we even permanently lower velocity in the name of quality.
I would suggest finding incremental ways you can get to your proposed end state and implement a little bit of it each time you touch that area, each sprint, and/or each time your prepare another test run (assuming it takes prep time - if not - fantastic!).
Improvements on Backlog
This is your choice and something you should discuss with your PO. Understand that while the PO wants high quality and improved output from sprints, the backlog is meant to represent valuable features/requirements from the user's perspective - not yours. For that reason, I would be hesitent to put improvement items on the backlog. You should ALWAYS be improving with each backlog item. Your PO may also balk at filling the backlog with things they feel should be done as part of normal delivery. Take it as a signal that this stuff is not directly valuable to the user, but a cost of delivering high quality value at a sustainable pace.