Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm starting to learn about Scrum, and I'm interested in trying it out with our development team. I have a lot of questions about it...but my biggest mental roadblock is in the actual graphical design.
With our current development cycle [waterfall-esque], our graphical designer lays out the page with all the imagery and such based on a loose PRD. If we were to utilize the methods of Scrum, how would this development take place? I think we're used to seeing the big picture and driving towards it...as opposed to fitting the visual pieces together as we go, which is what I'd expect the Scrum policy for graphical design to be.
Would it be unheard of to at least wireframe all the functionality in the backlog? Or would it be wiser to--for the first sprint--design its functionality in such a way that we can add the new features of other sprints as we go? (i.e. When it's time for a new feature, discuss "Where would this fit into the current design?")
here's how I'd suggest you do it (ie, how we have tried to do it)
Pre-sprint 0: make sure you have a good vision of what you want to do. Doesn't have to be super detailed, but should not be "we want to build a website which is social"
Sprint 0: Developers tool up - setup the CI servers, work on the deployment scripts etc, so all the basic framework is done. At the end of this, you should be able to push a button (worst case: run a single command on a REMOTE server) which takes the code in your source control system, builds it, packages it, runs all the tests you want on it, reports that back, and if possible, installs it on a test server (or atleast results in a package you can install on the test server).
At this time, the designer is doing the wireframes. Their aim is to do basic wireframes for as much of the site as you think you need (think sitemap and flow not fields and pixels). Then, when thats done, work out with the PM's whats most important, and go into detail on that - wireframe. Not pixels YET.
Project managers and the like are working with the designer and the business/stakeholder, writing up stories and tasks for you lot to do and track. Obviously, they need to have an idea of the sitemap etc to do this.
This may take more than one sprint. start with one (I recommend 2-3 week sprints - 1 is too short, 4 is too long), see how much you still need to do etc.
So at the end of sprint 0, you have:
Lots of stories, in priority order (you CAN add more later, infact you will always as requirements change)
A sitemap (ie, a general idea of what the whole thing is going to contain)
Wireframes for the first block of work
All your tools are working and setup
You CI, bug tracking, source control and deployment systems are in place
So then you begin sprint 1
Keep in mind that for the first 3-4 sprints, you will not know how much work you can do in the sprint, so EXPECT to get it wrong! Take off as much work (in the priority order the business/PM has put them in) as you think you can FOR SURE get done. you can always take more later!
You lot develop those pages, and the designer(s) wireframe up the next block of pages (as determined by the PM's). Maybe the designer does the art for those pages, so you can do it in the next sprint
So, you are developing what you have, and the designers are working on stuff for your next sprint.
Of course, they could have a scrum process going too, just they started a sprint earlier!
now repeat until you run out of work
during a sprint, if (say) a requirement changes or something new is added, then a new story is written for that, and it's scheduled into the work. If it's super high priority, it may go at the top and be the top item for the next sprint (which will be 1-2 weeks away, usually). Or it may be a nice to have, so it goes at the bottom - the business decides.
PM's/designers need to know they can change things, but changes DO have consequences, so it's not in their (financial) interest to chop and change back and forward. but requirements DO change, and XP and Scrum deal with this better than waterfall.
Dont forget:
you can stop a sprint at any time and go back to planning, eg if the requirements change too much, or you run out of work
you can schedule more work than you have time to do, as long as that work hasn't been committed to (ie, it's "extra" or "stretch" work)
Your PM should be able to predict when the project will end - look at how much work you did in the last sprint (your velocity), and divide the amount of work left by that number, and you get the number of sprints to go. Easy.
Oh, and read up on story points - dont estimate stories in hours or days. Use points. To bootstrap that, just make the first story you estimate (say) an 8 (the sequence is 1,2,3,5,8,13,21,40,60,100,infinite). Then take the second story, and estimate it relative to the first - is it double the work (13)? half the work (5)? about the same (8)?
At the end of the sprint, add up how many points you did, and that's your velocity. The max amount of work you can COMMIT to do doing in the next sprint is that amount. You CAN always stop the sprint early, or just pull more work off the backlog etc if you run out early. As you go along, your velocity will stabalize.
Damn, I'm sure there are books etc on how to run it, so I'll stop :)
I strongly disagree with the answer provided by Jason. The whole point of Scrum is to get rid of the method where designers first "do their thing" and then go on to other stuff. That's completely and 100% against all lean / Scrum principles!
The way to incorporate designers in a Scrum process? Throw 'em into the mix! Make sure you're not just wrapping a waterfall project into Scrum as that's the best way towards failure! Scrum only works when it's implemented without exceptions. "Scrum, but..." is the worst project model. Organize work so that it's possible for concurrent designing and developing. Don't overdo initial design, but make it a push-pull situation, where both sides of the coin influence the other. The point of Scrum is to iterate, iterate and iterate, so take full benefit from that.
Also, it's pretty lean to actually shun traditional Photoshop-based design altogether. You can read more about this from this excellent blog post in Signal vs. Noise:
http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop
I've done this before where the Designers did their thing in the early iterations, and their work product was used by the dev team in later iterations. As the dev team started work, the designers would move ahead to other parts of the project, or possibly to other projects.
I think we're used to seeing the big
picture and driving towards it
You can still do this. Your designers can do a bigger up-front design, and the dev team can use Scrum to iterate towards that.
For the the design part in sprint 0 you can use a technique like Styletyles (http://styletil.es) to determine the graphical style needed for the project. So you dont need a big design upfront and still be agile when you are sprinting.
It's easy peasy! :) Well, let me share how do we do it.
First Sprint
1) Product owner creates wire-frames and add to backlog (we use Yodiz, www.yodiz.com)
2) Our graphic designer create mockups and put them on mockup sharing tool (www.concept.ly)
3) Our developers work on setting up servers. If everything is already ready we have pretty smart Product owner, you will always have items in backlog to select.
Sprint Two
1) Developer start working on the finalized mockups, which were finalized on conceptly.
2) Designer work on other wire-frame added by product owner in backlog.
I told you it's easy!
I'd like to share . I'm the scrum master for a development team of a future social app. This team has in it 1 User Interface designer, 1 User Experience designer(me), 1 front end developer(css,ajax etc), and 3 programmers.
This is our first ever project using a SCRUM framework so it's been quite challenging. The trend during our scrum daily meetings is that our design work are never quite done done because our initial product backlog had stories like 'User wants to be persuaded to sign up' and then we added on that story a 'way to demo' so from there we could determine what needs to be done (i.e. we need to do wireframe, have copywriting done, etc...)
That, could be done better. Itemize every task based on that story, and estimate time for each task. For example, during product backlog, we could from there on create these in order: Site Maps > Task Flows > Wireframes
Now the question is, do we do all these in a sprint? Or should we do this even before any sprint? Defeats the purpose of scrum if we do out of sprints right?
Those who have done user experience design will know that these tasks take quite an amount of time to prepare. So why not make all these part of a sprint as well? Get programmers involved in these tasks as well.
Wireframing is very very important throughout the duration of the project. It's like the blueprint to a building, where its used from start to finish.
So, do an initial wireframe based on the product backlog during your first sprint. And adjust the wireframe accordingly during every other sprint. Our programmers will design their code based on the task flow and then create it visually based on the wireframe.
Oh, btw, dont bother too much about how the product is going to look like (tho having an intial design mockup is always a good thing). Instead, focus on the user needs and wants, and design a very user-centric flow to achieve just that. Our Designer later then figures out what kind of interface he is going to devise. If the wireframe was done proper, the designer will have very few problems designing the user interface. Same goes for creating copywriting.
In summary, work hand in hand during every iteration. For beginners out there (like me) give SCRUM a chance to work for you. If it can work for companies like fantasyinteractive.com , so can it work for you n me :)
p.s. for great wireframes, use omnigraffle (mac) tis the shite!
If we were to utilize the methods of Scrum, how would this development take place?
while this post is quite old, it prompted me to research on my own. i found Jeff Patton's "Twelve emerging practices" for UX designers/practitioners, which i thought to be apt to this question specifically, and quite a useful frame set:
Drive: UX practitioners are part of the customer or product owner team.
Research, model, and design up front - but only just enough.
Chunk your design work
Use parallel track development to work ahead, and follow behind.
Buy design time with complex engineering stories.
Cultivate a user validation group for use for continuous user validation.
Schedule continuous user research in a separate track from development .
Leverage user time for multiple activities.
Use RITE to iterate UI before development.
Prototype in low fidelity.
Treat prototype as specification.
Become a design facilitator.
if you'd like to dig deeper, jeff spells it out agileproductdesign.com.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm not against Scrum. I love it, it's right on my second preference right after RAD, however in my current team they made me hate it. We're possibly doing it in the worst possible way.
We have the usual Sprint planning which takes roughly 30 minutes while writing user stories ourselves and that's all. Right in that 30 minute we answer questions like the following:
What should the user do?
What is needed for this (Subtasks).
How much time will it take?
Okay we're done, see you tomorrow morning in the daily stand-up meeting.
This really frustrates me and they won't listen to me. There is no planning, like at all. At the point of (2) all 4 developers talking about different ways of solving a particular problem. It would be fine, but we also don't have any clarified vision and thus everyone has different understanding of where is the whole project headed. Thus our ideas completely differs. This usually ends up in chaos. For example the most recent story in our newest shiny project's first sprint:
Vision: We need an application to perform unit testing on X application.
User stories:
User logs in
Create DB table (No schema has been clarified)
Create Login View
Authenticate user to Y server.
User sees the available unit tests
Create a view to display unit tests
Read DB table
Implement CRUD operations
User executes unit tests.
Implement selection to the upper view
Add an execute operation
Display the result in a new page
What my worries were:
Vision doesn't say anything about where this whole project is headed thus we will end up re-implementing the majority of our functions when going to the next spring, or after that, or after that... (Checked - this happened right away; I can't help it I just hate to work on something that will be erased right at the start of the next spring. I don't think Scrum is about it, it would be really useless)
No actual planning. We haven't clarified anything what the DB should look like so how to create it? I can create a DB for such a system with 1 to N tables depending on what the project should achieve in the future but this is not so serious as a DB can easily be extended.
Based on (2) we started working on different parts. I created the DB while others created views and again others created operation implementations. All of us had different understanding and even in just a day we ended up with non-compatible models that just couldn't be integrated.
What have we done wrong:
No planning. My team just hates planning, they're like act first and ask later. I'm like: I.DO.NOT.DO.SOMETHING.TWICE.BECASE.YOU.ARE.LAZY.TO.DO.PROPER.PLANNING.
No communication between team members, but even I didn't expect that just under one day we will end up like that.
What is going wrong in here? Is it just me with the wrong understanding of scrum or my worries are true? This is giving me so much stress at work I barely can handle it anymore.
I'm intrigued as to who "they" are in this line : "This really frustrates me and they won't listen to me." ?
It reads as if you're referring to the rest of the scrum team. If so, I suggest you need to get to a "we" footing as soon as possible and work on communication.
With regard to some of the items in your post, a few things come to mind immediately:
If you don't have one, you need a product owner to own the product, it's vision and it's backlog. If you do have one, they may benefit from good training or coaching
You are absolutely right about needing a Product Vision. You seem to have one but, you infer that it describes some functionality rather than a complete product vision. If so, have you tried to discuss this within your team?
If you don't have one, you need a scrum master to help the product owner and development team to play by the rules of scrum and, in your case, encourage communication within the team. If you do have one, they may benefit from good training or coaching
Concerning your worries, I would add:
I think you mean 'sprint' where you write 'spring'
It is common in scrum that product backlog items are changed to reflect better understanding
You shouldn't need to describe the database in depth when you start a project. Scrum works best with emergent architecture based on implemented functionality
If multiple developers work in the same area without communicating, it's highly likely that you will step on each other's toes and get the outcomes you describe
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 at a small service based company where we are starting to implement Scrum practices, and we are also starting to use JIRA with greenhopper for issue tracking. Our team has defined "done" as:
coded
unit tested
integration tested
peer reviewed
qa tested
documentation updated
I'm trying to figure out whether this should be done using a separate issue for each item in the above list for each "task", or if some of these items should be implemented in the ticket workflow, or if simply lumping them together in one issue is the best approach.
I'm disinclined to make these subtasks of a task, as there is only one-level nesting of issues and I fear there is a better use for that capability.
I also am not too excited about modifying the workflow, as this approach has proved to be a burden for us in other systems.
If all of these items are part of the same ticket then that seems weird to me because the work is likely spread between multiple team members, and it'll be hard to make tasks that are under 16 hours that include all of those things.
I feel like I understand all of the issues, but as of yet I don't know what the best solution is.
Is there a best practice? Or some strong opinions?
Done is done - it has to be all those things you defined, however treating them as steps explicitly with a bug tracker can have the undesired side effect of encouraging divisions within then team and throwing stuff over the wall. So coders would claim they are done once ticket is marked "coded" and "unit tested", testers when marked tested etc.
This is exactly the opposite of what Scrum intends to do - the whole team commits to doing the stories so that they meet the definition of done in the end. So even though some of the elements of achieving done are indeed steps one should be very careful with solidifying these steps in any kind of defined workflow.
(This btw shows nicely why using a bug tracker as a scrum tool is a bad idea. Those are different tools that should be optimized for different things - even if linked together through some APIs.)
I certainly wouldn't nest them, since they are steps common to each task. Making them subtasks would just increase the complexity and boilerplate of the system. These seem like perfect workflow stages to me.
Something like Submitted->Assigned->Coding->Review->Testing->Finished.
Where Coding requires "coded", "unit tested", and "integration tested" before moving to Review, Review requires Peer Review before moving to Testing, Testing requires QA Testing before moving to Finished.
The only reason this would be tricky is if you're allowing Peer Review and Testing to be done in parallel. I see problems with allowing that, since if the code fails peer review and is subsequently changed it invalidates the testing work done by QA.
coded
unit tested
IMHO these belong together, as both should be handled by the same person (preferably TDD, which really makes it impossible to separate these).
integration tested
In our team, this is usually done by the same developer, so we typically do it as part of the above task. Other teams may do it differently.
commented
Do you mean code comments? Then, to me, this does not deserve a separate task. Otherwise, please clarify.
peer reviewed
A separate task for a separate developer (or more).
qa tested
A separate task for testers / QA personnel.
I would add documentation - it may not always be needed, but often is. Again, it should be a separate task, typically for the same guy who did the implementation (but not always).
One prime concern to practically all the Scrum teams I have been working with so far is to make sure that nothing important is forgotten from the above. Partitioning into distinct tasks may help this. Then you can clearly see in your backlog what's left to do. Lumping all of these into one task makes it easy to forget about this or that little detail. For us, it was most typical to forget about code review and documentation, that was the main reason why we turned these into independent tasks.
Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the definition of “done” does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration.
Reference: Scrum Guide - Written by Ken Schwaber and Jeff Sutherland (Inventors of Scrum)
You state that you are following "Scrum Practices". It sounds to me like you are just using a few parts of the Scrum Framework and not others, is that true? First of all, Scrum is not necessarily a practice, it is a Framework, you either use the framework or you don't. It works on the basis of inspect and adapt, so apart from the basic Scrum framework rules, nothing is set in stone, so you won't get an exact answer to your question. The best way to know the answer is hire experienced Scrum Professionals, and Experienced Developers and Testers and try the above done plan in your Scrum Team.
Remember always Inspect and Adapt. There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.
Do not spend loads of time documenting or looking for a solution to a given Process problem because most of the time the problems change faster than you would realize, it is just better to inspect and adapt provided you have at least the basic knowledge of scrum and you are using the Scrum framework and not just a few Scrum like practices.
We use a pretty similar system in JIRA and I have an open question here and on the Atlassian boards asking a very similar question. We have a similar definition of done. We create the main story in descriptive form i.e. "The legend text on the profit and loss graph overlaps". We then define sub-tasks which are either of type 'technical' or 'process'. Technical tasks are the actual work of implementing the story "Research possible causes on vendor site", "Implement fix in the infographic class". Process items include 'Peer Review', 'Make Build', 'QA Testing', 'Merge'. As one comment noted you may have QA going on before/during Peer Review. As a part of the Scrum process we have QA going on nearly all of the time (they are part of the team) sometimes they sit with the developer, sometimes they get 'bootleg builds' to run in a test environment. This is exploratory testing and is considered part of the coding process to us. The sub-task for 'QA Testing' is for integration and regression testing and is a final validation of the whole story after Peer Review is completed. By that time the QA team already has a complete test plan they worked up during exploratory testing and it's typically just a matter of running through the plan and 'checking it off'.
We've gotten to this point after running sprints for a year and making changes during the retrospective. I'm open to suggestions as I think one of the downsides to the retrospective is that you can group-think yourself in one direction with little hope of ever backing all the way out and considering a different path.
We use two boards for this purpose. We have one board for the Development Sprint where "Done" is Ready for Testing. You can't enter a sprint unless you're well and truly ready to start development (all analysis done, estimates done, people know what they are supposed to be doing - all the conversations have been had, shall we say, though our conversations tend to take place in JIRA Comments given the distributed team) ... and you exit when you finish development. That's the best way to track whether our development team is meeting their own goals without being impacted by QA. Meanwhile, QA uses a Kanban style board and they go from "Ready for Testing" (this is their "to-do"), through In Testing to Ready for Release.
We switched to this because we previously had all these steps in a single board, and we weren't "meeting our commitments" within any sprints because there was no way to both develop & test all in a single sprint, where we have to do a code migration to the QA environment for final testing to occur, although testing is happening all along the way. We are still trying to figure out how to do things correctly, so this may not be the right answer, and yet it sounds like it's not something you've thought of, so maybe it would work for you.
and it'll be hard to make tasks that are under 16 hours that include all of those things.
This is your real issue; ability to break down stories into small useful vertical slices of functionality. Working on this will make your team more agile and give the PO more flexibility.
To the contrary, breaking down the work by process/mechanical step will only make you less agile and really serves no useful purpose. Either you are done or you aren't; no one cares if you are dev complete and not tested so don't bother tracking it by the hour....its waste.
Refocus on your stories, not on tasks.
We use subtasks.
Given that the story is a shared item (the whole scrum team works on it), we use the subtasks as 'the post-it notes' allowing to track tasks which individuals need to tackle.
We don't require that every little piece of task is represented as a subtask.
We are not bookkeepers, but developers.
The team agreement is that if you can't take up a task immediately, just jot it down as a subtask to the story. (Using the agile plugin, it is really easy). ie. we will never have systematically a subtask 'create unit test', but in some occassions, when someone is struggling to get that dynamock up and running, you will see this subtask popup in the story. Having it there allows the team to discuss it during the scrum.
If you want to generate the checklist automatically, look at the create subtask on transition plugin.
https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition
It allows you to automatically add the subtasks when the story has been committed.
BTW - JIRA is more than a bug tracker. We are using it in a wide variety of applications,
including the management of our sprint activity. (as an Atlassian partner, I'm biased :-).
Francis
Important thing is that you use sub-task as real task; not as activity of main task. Issue tracker is primarily meant for what you are doing; not how you are doing and in what order.
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
If everything in scrum is all about functional things that a user can see is there really any place for refactoring code unrelated to any new functional requirements?
I don't think that this has as much to do with Scrum as it does with project management philosophy.
Regardless of whether a project uses Scrum or not, many project managers do not like developers spending time on "unnecessary" things like code refactoring or restructuring that doesn't directly advance one of the outstanding functional requirements. It's not "work that yields results" like normal development, it's "work that prevents a delay of results later". Given the typically short time-lines used for Sprints, the benefit is often hard to see and nearly impossible to quantify.
Keeping code maintainable needs to be an item on your burn-down list (if you use a Scrum). It is just as important as new development. While it may not seem like something that is "visible to the user", ignoring it increases your technical debt. Down the road when the technical debt piles up enough that your code's lack of maintainability slows down development, the delays in new feature development will be visible to customers.
It's all a matter of management/philosophy. Instead of looking at refactoring and maintainability enhancements as "extra" work that doesn't impact customers, it should be viewed as a time investment to prevent customer-visible delays (and potentially bugs as well) down the road. Developers can sometimes see these benefits more clearly than managers can; if your manager doesn't understand the disadvantages of neglecting maintainability, you might want to grab several other developers and have a chat with your manager.
I think there is a fair case to make for technical debt refactoring where the effort/cost impact of maintaining the code is as high as, or higher even, than the cost of refactoring it to improve quality or work better / properly - specifically to lend it a higher degree of maintainability.
eg: if the software is so problematic you are losing customers, or money, you'd act fast to fix it.. Some might argue this is a business requirement of it's own, but it's often not placed front and centre on small to mid sized development projects, which instead focus on the technicalities of creating apps rather than the impact of the quality of the app on the bottom line.
I think you are probably talking about large scale refactoring rather than the continuous refactoring you would do whilst in the whole red-green-refactor cycle.
My approach would be something like this, if reafactoring an old feature makes it easier to add a new feature then go ahead and do it. But in some ways you are right, if there is no pressure on a particular unit to change (i.e. it is completely finished and will never change again and will never impact on other modules) then there is no practical need to refactor. However I rarely find a module that is quite so finalised.
If everything in Scrum is all about functional things that a user can see (...)
Any project and methodology should be about generating business value, you rarely do things just for the fun in a business environment. Having that said, I see quality in Scrum (and other Agile methods) as a way to not kill your velocity on the long run and, ultimately to achieve hyper productivity. I thus believe that a typical "Definition of Done" should include something like "no increase of technical debt" (put your quality standards in there). If you think a new feature will impact existing code that should be refactored, include this cost in the estimate (or create a refactoring item in your Product Backlog) and explain things to your Product Owner. Because at the end, it's up to the Product Owner to prioritize items and to decide if quality can be sacrificed temporarily (if your business die because you don't release a feature, what is the point of refactoring existing code?). But he must be aware that this can't be a long term strategy or he will kill the team velocity.
bta: Regardless of whether a project uses Scrum or not, many project managers do not like developers spending time on "unnecessary" things like code refactoring or restructuring that doesn't directly advance one of the outstanding functional requirements.
Definitely a noteworthy observation; my solution to this would be as follows:
Perform regular code reviews. Every code review should recommend actions to improve on deficiencies in the code.
There is now a requirement for jobs which improve code quality. Build these into the sprint and track them in the same way as any other job.
If your manager needs any more convincing, cast 'the maintainer' as a user, and describe some user stories for them - and then 'features' are things like 'the code is fully commented with xml doc comments' and 'the code does not produce any warnings from ReSharper'
If you can justify it as part of the process of completing other tasks by identifying issues/risks with current sets of code, and it is a better end result, go for it. But don't get overzealous and screw the timelines/budget.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
In a scrum team, how important is it to complete a single story before moving on?
Our scrum master is fairly dogmatic about bringing a single story to completion before moving on. I can see that development would appear to be more "controlled" in this scenario, plus the scrum master would have a very accurate picture of what team members were working on at any given time... but I am interested in what this really buys us?
Clearly the scrum master wants to minimise divergence of the burndown from reality to avoid a shock come the end of the sprint - but surely if the sprint is two weeks long, the burndown is updated consistently and blockers are communicated at standups - any such divergence will be constrained by the sprint length, and be made visible mid-sprint through the usual channels (i.e. the standup or speaking to the scrum master individually). Any remaining issues can be dealt with in the fortnightly retrospective.
The reason for the question is that I seem to find I work most efficiently by keeping say 2 (or 3 if one is particularly easy) stories in progress at any given time which I work on as I see fit. This seems to assist with the sub-conscious background thought that assists with completion of the task. It also permits me to better understand the bigger picture if a couple of stories are related.
Our stories usually work out to be one or two days worth of work.
So, is working on a couple stories at a time frowned upon and if so what does one-story-at-a-time buy you?
i think it really is up to the team to decide. i think you hit it in your write up about the burndown, the most important thing is to meet your sprint commitments consistently. how that happens really should be up to the team if they truly are self-governing. the team im on now, our norm is to work on multiple stories at once; its the nature of our setup given that we try to really spread ownership of stories across the team. it may be a different norm for yours if you have shorter stories and more of a individual ownership style.
I personally think one story at a time works well because it keeps you focused on a task. The cost of context switching between multiple stories can be high. This is a personal preference for me, but different people work differently. Though I think your scrum master is correct in his methodology, if you've found very compelling reasons for multiple stories at a time and can demonstrate that it is in fact helping progress, that would be a good case to make.
IMO, there is an underlying question here. Sometimes when working on a story, I'll need something from another department/team,e.g. clarification on a requirement or a graphic for a page, and this means that I won't finish one story before moving on to another story. While you do mention this in discussing the blockers at standup, this can happen where it is up to someone outside to help me finish a story so there can be multiple ones on my plate. Thus, I can have multiple stories due to blocking on something and still wanting to be productive.
In general, I don't like trying to manage multiple copies of the code base or switch my code a lot, so I prefer doing one story at a time, assuming no blockers. The size of the code base I'm working with is ~1.1 GB of data spread over 82,000+ files so having multiple copies could be more than a little painful I'd imagine.
My personal guess on this is that it is up to the team to set the standard and see that it works for them. If some like one story at a time and others do multiple and all is well, cool. If everyone likes having multiple stories at various points of completion, that can work too.
Don't hog the backlog...
In my experience, when stories are between 1 and 2 days in size, they tend to be implemented by a single developer. If you are working 2 or 3 stories concurrently, that might reduce the amount of things in the backlog that other developers can pick from and jeopardize the sprint.
... but plan for blockage
On the other hand, working 2 or 3 stories at once means that if you are momentarily blocked on one story you can be immediately productive on the other. I find that there's some overhead each time I start a new story. This overhead makes it hard to fill an hour long "gap" in my day with a new story, whereas it's much easier to context switch to a story I've already started.
Bottom line, let the team decide... and then review results during a retrospective. If your stories, tasks and work process support an environment where team members can work 2 (maybe 3) stories at a time without sacrificing productivity or predictability, then your SM should respect that. But at the same time you should honestly review the results during each retrospective and be prepared to change if the SM doesn't think its working.
I generally would think that the decision on how to work best should be made almost exclusively by the team. The ScrumMaster's role is to help and support the team, not to question the team's way of working during a sprint.
To be fair, sometimes it can be a good idea for the ScrumMaster to point out possible flaws or risks - that would fall in the category "help and support". Being dogmatic about your personal idea about how a sprint should look like internally is not something I would want a ScrumMaster to act like. It sounds a bit like misunderstading the role as a manager's role, which is simply not the case.
As for how we do it: We almost always work on several stories at once. At the moment we're having a four-person scrum team with three developers and one tester and we nearly always have at least two or three stories going at the same time. In the last sprint we tried to start with all stories early in the sprint to get to the point where we have a basic design and a good idea about what the potential problems could be. Of course we were not working on all stories at the same time after that.
I understand that in terms of risk-management you might want to make sure that everything is done for one story before you tackle the next. However, the disadvantage is that when you run into unforeseen problems lateron, you might not have enough time to fix those. Usually problems show their ugly faces during the implementation phase and often enough quite early. So, you basically exchange one risk for another.
Which risk is easier to handle shoud be up to the team. It's their sprint after all and while I think it's perfectly fair for the ScrumMaster to mention concerns about the way the sprint is going, he shouldn't force his idea of the best way to work on the team.
In the end, I think it boils down to these two things:
YES, we do work on several stories
at once and it has worked out fine
so far.
Remember that the ScrumMaster is
working for the team, not the other
way round.
Please note that I'm mostly talking about the whole team working on several stories at once, not one developer. The problem I'd see there is that you need to make sure that you don't block any stories by keeping them open, so that no-one else can continue the work. Once again, this is a question of circumstance and preference. When it comes to testing, our tester often has a couple of testing tasks for different stories, so that he can easily switch to a different task, if some bug blocks him from continuing testing a feature.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.
Have you any recommendations for improving the the quality of input from the functional people?
Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Have you tried working with your customer to define / formulate acceptance tests?
Using something like Fit to come up with these tests - would result in better specs as well as force the customer to think about what is really required. The icing on the cake is instant-doc-executable specs at the end of this process.
That is of course, if your customers are available and open to this approach. Give it a try!
If not (and that seems to be the majority - because it is less work) - calendar flash 'em - schedule meetings/telecons every week until they sing like canaries :) +1 to Dana
Sometimes the easiest way to get input from people is to force it out of them. My company used SCRUM on a project, and found very quickly that people tend to keep to themselves when they already know what they're doing. We ended up organizing weekly meetings where team members were required to display something that was learned during the week. It was forced, but it worked pretty well.
I'm a big believer in Use Cases, detailing the system behaviour in response to user actions. Collectively these can form a loose set of requirements, and in a SCRUM environment can help you prioritise the Use Cases which will form that particular sprint's implemented features.
For example, after talking to your functional team you identify 15 separate Use Cases. You prioritise the Use Cases, and decided to plan for 5 sprints. And the end of each sprint you go through and demo the product fulfilling the Use Cases implemented during the sprint, noting the feedback and amending the Use Cases.
I understand that the people you call functional people are acting as Product Owners, right?
I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?
Actually, without having any specs you probably have no acceptance test for the backlog itens as well. You should ask the PO to write the user stories, I like the "As a - type of user -, I want -some goal- so that -some reason-." form. Keep in mind that the User Stories shall be INVEST - Independent, Negotiable, Valuable to users or customers, Estimable, Small and Testable. What is a must is to have the Acceptance tests written together with the story so that the team should know what the story must be able to do in order do be set as done.
Remember that as the product evolves, it's expected to the PO have ideas as he sees the working product. It's not a bad thing, actually it is one of the best thing you can get through Agile. What you have to pay attention is that this ideas mus be included in the product backlog and it needs to be prioritized by th PO. And, if it's necessary and will add value to the customer, the idea should be planned to be built in the next sprint.
Someone from the functional team should be part of the team and available to answer your questions about the features you're adding.
How can you estimate the Backlog item if they are not detailled enough ?
You could establissh a rule that Backlog item that do not have clear acceptance criteria cannot be planned.
If would be better to have someone from the functional team acting as Product Owner, to determine, choose and priotitize the Backlog items, and/or as Domain Expert.
Also, make sure everyone in both the functional team and the development team speaks the same language, so as to avoid misunderstandings ; See ubiquitous language.
Track the time most waiting for answers from the functional team as well as he time wasted developping unnecessary features or reworking existing features so that they fits the bill.
Are they participating in the stand-up meetings?
You could propose to have a representative at each (or some) of them, to ask them for input before the end of the sprint
Are you doing stand-up meetings and do you have burn down chart? I think those two areas would benefit you greatly.
I recommend the book "Practices of an agile developer" it is full of suggestions how to make a scrum team successful. It also gives good tips how to get the product owner/customer more involved and how to get the whole process rolling. It's worth the money IMHO.
I agree that you need some sort of requirements (user stories or else).
One piece of advice I can give is to use some sort of visual aids with the functional teams. When customers have plenty of ideas (as you've said) they usually also have a visual idea of what a feature looks like, when the developed product doesn't fit this visual idea it creates a lot of doubts, even if it does the job functionally.
When discussing functionality with customers, I try to be very visual. Drawing sketches on a board, or even verbally describing what something would look like. Trying to find a common visual image. You can then take a photo of the sketches and use them as part of the documentation.
Another advice is to keep your sprints as short as possible, so that you do more frequent demos. But you may already be doing this, since you didn't mention your current sprint duration.