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
While Scrum is easy in theory and hard in practice, I wanted to hear your definition of Done; i.e. what are the gates (unit test, code coverage > 80%, code reviews, load tests, perf.test, functional tests, etc.) your product has to go through before you can label the product "Done"
We at TargetProcess use the following definition of Done for user story:
Short Spec created
Implemented/Unit Tests created
Acceptance Tests created
100% Acceptance tests passed
Product Owner demo passed
Known bugs fixed
I'd say it is up to your team to decide. Talk with the product owner. Ideally done would be when a story is in Production and being used. However, there is a time gap between when a story is development complete and in Live. Makes it hard to track how long a story took to develop.
In my team, our definition of done is, when the developer completes a story,and does a "show and tell" to the rest of the team(testers, product owner), and if everyone is happy it goes into the subversion trunk.
Further testing is done off a automated build from trunk.
In a perfect world, the product shall be in a shippable state at the end of every iteration.
Now this actually depends on your product, your market, your customers and might not be possible.
If you cannot achieve this, then the next planning horizon apply: the release.
The Team as a whole should decide what is required to ship the product and plan accordingly.
What helps here is to define "done" at the task level. Defining done here is much more simple: one task is done when you can start another one: everything is tested, integrated. The Team can alo define this state: documented, reviewed, included in automatic build, no known problem, accpeted by On-Site Customer ...
Having all your tasks really "done", Having all tour backlog items (or User stories, whateveryou call them) realy "done" allow to be "done" at every iteration, which helps preserving the product in a shippable or deployable state.
There are three nice articles by Mitch Lacey, Dhaval Panchal and Mayank Gupta on this on the ScrumAlliance website.
EDIT: Basically the whole point is that done is defined on a project-by-project basis by the team. The basic need is to agree on the definition, not what the definition is.
Everything that will make your "stabilization period" (ie work required between the code freeze and the release to the client) shorter.
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
Just had a quick question about Agile Development in terms of number of assigned user stories - per developer - in a sprint...
The gist is this: in a 10 day sprint, I had 2 stories that were assigned to me. The stories were very much related, and the second story clearly piggy-backed off of the first.
In Agile Development, is it acceptable to have worked on the initiative / acceptance criteria of both stories in one branch, and have the logic for both stories pushed up for a pull request / code review in that same branch.
The 2 user stories do have their own individual story numbers in our sprint management software. The first story was essentially rendering a component with 2 links, and the second story was making those links either go to a specific route (condition 1), otherwise they are each to open up a specific modal (condition 2).
During my code review, one of the devs asked why I did this, and suggested I should have waited for the first story to be not only code review approved, but accepted by QA before even beginning to work on the second story, saying that I added unneeded complexity for QA, and delayed the chances of the stories being accepted in the current sprint.
My argument was that (besides the constant and unnecessarily long time it takes for the code review), it did not make sense to finish the first story, then sit around and wait for it to be accepted before beginning the development on the second, ESPECIALLY due to the simplicity of it.
The flip side, had I started developing the second story, there would have either been unnecessary duplicate code (to render the necessary component from the first story) to test the new logic, or lots of going back-and-forth between branch-1, branch-2, and develop; not to mention using git rebase (which I'm down with, just sayin) on each branch (git pull new changes into develop, run git rebase develop on branch-1, then run git rebase branch-1 on branch-2. Just seems convoluted)
To be more efficient, and because of the minor criteria of the second story, I did all of the coding efforts in a single feature branch.
Whew! This was far more long-winded than I intended; sorry about that...
TL;DR -- is it ok for a developer to work on more than one separate user stories at the same time during a sprint, in a single feature branch? So long as they are very closely related and piggy-back off of each other..?
It sounds as if the user stories were mis-defined in the first place: From the user's perspective, what's the point in having a link in the UI that does not point anywhere? This is the situation you would have ended up with if your story1 got implemented without story2. I.e. what you refer to as user stories are not in fact user stories, but two tasks that belong to a single user story. To resolve the situation, this should be reflected in the management software.
But more generally, after the sprint planning meeting, there should be no questions left open regarding who does work on what tasks.
Answering your question, in general of course it is ok to work on more than one user story, but inside the team it should be clear to everyone who does what before one starts the work, and the general organisational conditions (QA of user stories, in your case) should be taken into account. Communication is key. If you think the user stories should be structured differently or some things do not make sense in isolation, let the others know about your opinion before you start working on it. The sprint planning meeting is the best time for this kind of discussions, but your scrum master should always be open to discuss. This way of handling stuff should avoid surprises for your teammates.
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.
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
When designing a back-end system, what granularity do you normally give your stories and tasks?
Most examples of creating stories and tasks usually center around a GUI application with the story being something the user can do (e.g. search for a book by the ISBN) and each task centered around enabling this GUI feature.
When designing a back-end system, i.e. one that doesn't have a user interface but is just a bunch of services talking to databases, middleware, etc. how do you come up with tasks and stories?
Basically, I try to keep the size of my User Stories in the area of 1 to 10 man-days to complete. That keeps me from passing what Mike Cohn calls "Epics" or "Themes" as user stories to the developers, and on the other size stopping my user-stories to be so specific as to imply the solution (they should be describing the problem, not how it should be solved).
As far as content goes, I make sure that my stories contain only business value - it never describes how I (should) satisfy the demand, nor does it "require" non-user-domain knowledge to understand.
Good example: As a content manager, I want all users to have to log in before writing a talk-back, in order to deny them the ability to spam.
Bad example: Add captcha to the web site.
Tasks, on the other hand, are steps towards solving the solution - they describe components & functionality that need to be added / modified. This is where an "Add Captcha" solution comes in. As far as size goes, I try to have each task's size be between 1/2 a day and 2-3 days of work.
Tasks also include a set of standard tasks that apply to each and every feature / requirement / problem / bug, such as:
Document
Write Test Cases
Manual Test
Write automated functional tests
etc.
Hope this helps,
Assaf.
As long as you have users, user stories can be around things users can do. If you are providing an API for other developers, then they are your users. Things will get more technical at that point (i.e. User can update Employee records)
I base the stories on the public interface of the classes. For task granularity I shoot for work effort of half a day to two days.
A user/ actor can be a system, not necessarily a person. Your services will have an API, expected input and results and a service level agreements (non-functional requirements). All of those can be specified in the story card.
Most importantly, your story card should specify acceptance criteria. Accpetance criteria will help drive the developers Test Deiven Development Unit Tests, the automated functional tests and the automated performance tests. If the acceptance criteria is meet, the card is accepted and approved by the product owner.
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.