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
In out project the workflow of user story is ToDo - In progress - Dev - SIT - UAT
now the challenge we are facing is in calculating the velocity
Because we give sorry point considering the effort involved in development, SIT ,UAT testing. But at the website is sprint we are able to just push our user story to dev and not able to complete SIT and UAT in a sprint.
Now what is the right approach to calculate velocity ?
Velocity is a measure of the amount of work a Team can tackle during a
single Sprint and is the key metric in Scrum. Velocity is calculated
at the end of the Sprint by totaling the Points for all fully
completed User Stories.
https://www.scruminc.com/velocity/
As you are not completing stories, your velocity is zero. If you keep a project burn-down you could see some earned points when you complete the SIT/UAT. This could give you an idea how much work is done and when the project is completed.
The Development Team consists of professionals who do the work of
delivering a potentially releasable Increment of "Done" product at the
end of each Sprint
https://www.scrumguides.org/scrum-guide.html#team-dev
Guess you need to figure out how to get your work DoneDone within a Sprint. The idea is to really finish work in a Sprint, this can be a challenge, but experiment with reorganizing your work to make it happen.
Wouldn't it be nice if, once you finished a story, you never had to
come back to it? That's the idea behind "done done." A completed story
isn't a lump of unintegrated, untested code. It's ready to deploy.
https://www.jamesshore.com/Agile-Book/done_done.html
I would take some time during the next retrospective and discuss how you can complete stories within the Sprint. What would it take?
I would suggest Swarming a single user story and getting it DoneDone, before starting the next.
Note impediments and fix them to deliver faster:
If you cannot execute System Integration Tests during the sprint, invest time to make it easier to deploy to a test/staging system.
Schedule regular time with users todo User Acceptance Tests, or invite them to the Sprint review and let them play around with it. Create new stories for things they find.
Try splitting stories to make them smaller, so it easier to get the really done.
My recommendation would be to measure number of storypoints thats been taken from the start of your workflow to the end of the workflow during a given timeperiod(Days, weeks, months etc), that will give you the teams velocity in storypoints.
What if:
integration testing is fully automated
if not, you have a tester full time in your team who tests as soon as a story is deployed on the SIT server (automated deploy by Continuous Delivery tool like Jenkins)
someone is accepting a story as soon as a developer says “take a look at it” (can even be done on your laptop)
the product owner is the person who accepts a story
in the Sprint Review (“demo”) you show the new Produxt Increment to users and request for feedback
... then you get flow and you have only three statusses: To Do - Doing - Done. And releasing/deploying to production is just another Story in the sprint.
... then Jira tells you your velocity and you can use all those other very helpfull reports in Jira :-)
... and everyone in the team is happy because there is flow. And features are delivered fast to end users.
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 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
Quite often I would complete numerous daily tasks i.e. not working on anything one component in particular. Therefore, I find it quite difficult to remember these individual tasks in our next day stand up meeting. Is it ok to bring a small sticky note with a few reminder points on the previous days tasks? For example, the contents of the sticky could be:
Yesterday:
----------------
- Implemented component X
- Refactored Y class
- Updated Bamboo build settings
- Submit test request to 3rd party harness
- Read up on X API
Today:
----------
- Write tests for component B
- Implement component B
- Document install instructions
- Code review meeting
Obstacles:
----------------
- Sys admin still haven't opened external port
What are your views on this?
A key point of scrum is that it's not written in stone -- you should adapt it to whatever works best in your organization. However, the daily standup meeting is meant to be short, so if you bring notes, you should use them as a reference, not like a meeting agenda.
Yes, short notes are fine. Long stories probably destroys the relationship with your coworkers.
Implement Scrum in a way you feel it comfortably. Stand up meetings should be short, but who is saying that they can't take so much time as you need it?
If you are using some kind of Scrum tool, you don't have to take your notes, all is written in tool - obstacles, tasks status, comments.
I don't know if it is "officially" ok but I do this all the time. If you are like me and lose track of the last thing you did because you are now focusing on something new then write stuff down. Its better to show up at SCRUM with a short list then to show up and say: "now ... what was it I was working on?".
I think notes are ok, but you are talking about subjects which may not be pertinent to user stories in your sprint. If you keep focused on that rather than other tasks that you have performed you will keep the scrum meeting short and relevant.
If the tasks are relevant say what story they were part of to give co workers context.
I don't see any reason why it wouldn't be OK to bring some notes to the daily meeting.
In our team, we have extended the daily scrum a little bit. It consists of the following parts:
The normal daily scrum (yesterday, today, obstacles). This should not take more than 5-10 minutes.
We update the sprint backlog. Should not take more than 5 minutes. This ensures that the whole team knows about the the current state of the sprint backlog.
If required, we discuss any important topics (which concern the whole team)
If required, we schedule meetings between team members (or directly hold the meetings after the daily scrum).
Because of the way we do the daily scrum/daily meeting, it is quite normal that everyone brings some short notes, for example about what topics they need to discuss with others.
After all (as others already mentioned), you should implement SCRUM in a way that works for you and your team. And of course you should always be open to improve/change your process if you found some problems (e.g. during a retrospective).
Why would they not be?
Only rules are:
Answer the three question
what did you do yesterday
what are you going to do today
what is blocking you
you speak to the team (not any one individual)
you keep it short
no story telling
no problem solving
speak when you have the token
know who to send the token to next (not someone that has already spoken)
if someone goes long or tries to problem solve others may call for a focus meeting after the stand up
Story card wall should be visible
A person in the room updates the blocker boards as blockers are called out
Notes are fine, as are projectors, laser pointers and beanie caps with propellers.
The answer to the basic question is yes. It is entirely appropriate to bring notes to a standup if it helps you.
Your example, however, points to a common pitfall in standups... providing detail on activities that may not be important to the team. You read something, and you attended a meeting. Those are examples of what I sometimes refer to as "justifying your 8-hours".
The key is - share what you did and what you will do without elaboration. If someone has questions on something particular, they can ask for details outside the meeting.
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.
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 9 years ago.
Improve this question
We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.
EDIT: Additional Information:
We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.
EDIT: More insight/confusion perhaps:
I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.
Don't wait. Build a prototype based on whatever minimal requirements you do have and get feedback ASAP from the product owner. More often than not they don't know what they want anyway - if you can show them something tangible as a starting point you're more likely to get useful feedback. Also, once you have a better idea of the real requirements you will probably have already gained a lot of insight from developing your prototype.
If I understand your situation correctly, the BAs are the ones falling behind. There are two things you could try.
Try either small sprints or smaller requirement chunks. Either way the work for the BAs should be more concise and managable.
Take an interation to rework or bug squash. That should give the BAs sometime to get ahead of the curve.
If, however, the problem is that the BAs need to see the previous requirements in the "wild" before making more requirements you have much bigger issues. :)
At a previous position we managed this by asking our business customers to be a week ahead or so. Sure this breaks from some of the strict interpretations of agile but it made things so much easier. We would have both testing and the business working a week or 2 off from development so when developers were working on iteration 2 testing is working on what came out of IT1 and the business is on IT3. Priority was always given to active development so sometimes it broke down if a story was particularly flexible (i.e. the business had to spend lots of time revising things mid iteration) but overall it worked well.
Update to respond to the questioneers Update
It seems to me those don't really stand on their own as stories then and maybe the BA team needs to reevaluate how they are writing stories. I mean you can't reall "tell a tale" with customize X screen. In theory a story should be something like "When the user goes to screen X they should be able to modify (and save) the floozit"
Sounds like the BAs may not be handing you your user stories for the sprint in a timely manner.
I take it that there is no sprint planning sessions from what you say.
Given that one of the big tenets of Scrum is that the development team takes responsibility for what they will work on per sprint, it sounds like this ain't too agile to me! (-:
Apart from having short sprints that is.
Well, a couple of things might help
- In the SCRUM process, there is the concept of Product Owner wchich is a Pig Role, this represents the customer. So you can invite the PLM or the client's main contact to your SCRUM's meeting. This will give your customer's some buy-in into your process and will get them to work "with" you on your goals
- Weekly builds to the client might help. So, the basic idea of the weekly drops is to show the customer "progress". So if for a few weeks there is no progress, this should raise the question "why?" and then you should be able to explain that it is for the lack of requirements finalization.
Hope this helps
the "user story" is a placeholder for a future conversation, so get in front of the customer and ask them; if that's the BA's job, light a fire ;-)
Your user stories are incomplete. 'Customize X screen' is a task, it doesn't describe any requirements or completion criteria. The user story should be something like 'Allow Nancy to see the related purchase orders for an item in inventory'. Then break that down into tasks during your sprint that you can work on.
Once the BAs have developed a workable user story then add it to your product backlog, prioritize it, and plan your sprints for the top backlog items. The BAs should be developing user stories and adding to your backlog independent of your sprints, and thus not blocking you. During a sprint the tasks are completed and the user story does not change. After releasing the customer provides feedback which goes into the product backlog as more user stories.
I see a few ways to handle this:
Option 1, Under SCRUM, you should have a Product Owner who is managing your product backlog, which is supposed to contain requests for features of the software. If the feature consists of something vague like 'Customize screen X' and you decide to add that to your sprint, then the sprint tasks should be concrete, decomposed tasks, and I would say one of those tasks has to be 'Define requirements for screen X'.
During the daily SCRUM, when you're asking your three questions of each team member, the developer who has that screen mod task will say "I'm blocked waiting for requirements from the BA.", and your scrum master does what they can to get that moving along.
option 2, in my opinion, is that items do not go into your product backlog until they're defined well enough to do at least some productive work on. We all know requirements change, but the point is that you're supposed to have enough to start with.
Easy.
Allow yourself to think outside of Scrum's strict rules, and get back to your lean roots:
http://availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/
http://leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
Trust me, once you get that flow going, you'll never look back.
As it is said above, usually at the beginning of each sprint you should prioritize the existing backlog and pick some stories for the current sprint. If there is not enough user stories for the developers, you should shift developers to another project and let the product owner some time to create a decent (=large enough to feed some team) backlog for the project.