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.
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
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.
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.