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 starting to use a Scrum process for development. We have a nice stack of user stories now . I'm wondering though, once a user story is complete, tested and deployed do you do anything else with it? We're using little index cards right now, I'd think it would be fine to just toss them in the trash can.
If you keep them, what do you do with them later?
Archive them for reference on future projects. They will be useful when you have to estimate story points. Often times, similar-sounding stories occur across projects.
Um - keep them and put them in the project file. CYA in all cases. You never know when a client will come back and ask you "why is this this way?", or "who decided that was how it was?". You can then pull out the user story and have backup.
Always keep everything like this until the warranty period has expired on your software... unless you want to be put in the position where you could be asked to "fix" something that was really a change for free.
The trash can seems like an appropriate place.
PEZ is almost right. Recycle the cards rather than trash them. :)
There really is no point in keeping them. If you need a history of changes you can get that from your SCM and test scripts.
Another vote for keeping them. I know it's a dirty word, but the user stories are part of your documentation, and serve an important purpose.
Three years from now when you (or the inheritor) are making changes to the system it's helpful to have the historic documents to know why you did things the way you did.
It also helps when the situation changes and you have to rewrite to be able to go back over the user stories that the application satisfies and determine whether or not those same stories apply to the new version.
I usually wrap each iterations worth of user stories (and tasks) in a rubber band and a new card in front stating the velocity and estimated points. I've never had any use for them though, except for nostalgic reasing. So keep them for the archive I'd say :-9
Hang on to them!
I write requirements (rather than code), but I frequently find myself rereading old user stories and acceptance tests (mine and others').
Reviewing old stories can help me find the clearest phrasing for complicated concepts, rather than reinventing the wheel. They sometimes serve as a useful reminder for details I might otherwise forget to document. Stories written by others help me come up to speed on features I wasn't involved in, and will probably be a good learning tool for new hires.
I could go on, but let me just put it this way:
Which is more likely to cause greater problems -- keeping the stories and not needing them, or needing the stories and not having them?
Keep them (archive them) so that if there is a dispute or argument over something in the future, you have a reference to it, and can cover yourself.
Completed user stories are essentially the final specification for your project. If you started with a formal requirements document or specification, there are many lessons to be learned by comparing your completed user stories with that document. If you don't have an initial document, then your completed user stories document the functionality of your project. In either case, I think it's very valuable to hang on to them for future reference, whether in project post-mortems or when estimating and planning subsequent projects.
I find that we never know what's going to be useful in the future, so my recommendation is to tag them and file them. If you're using physical cards, scan them then do something as simple as adding a tag to the image file. Imagine looking at a tag cloud later to find common threads or to locate and re-use your content.
As with all things scrum, though, if it starts taking too much time, it's probably not worth your effort. Don't make it a crazy process, just quickly file it and forget it.
Cheers,
Reeves
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 5 years ago.
Improve this question
The company I work for is currently looking to move from traditional waterfall into Scrum for development. We are in the process of slowly adopting what practices we can without fully making the move (we still have much to learn before we can fully move on over!).
One of the things we want to implement now, before making the full switch, is the taskboard. We all feel it's a great tool that can help with development, and help keep those business users off our backs with the "what you doing?" and "how's it going?" questions and meetings.
So with all that said, one thing I've been wondering is can the tasks on the taskboard change? I know you don't want to be changing Stories, but what about tasks within a story? What if a new task came up, or an old task is no longer valid? Can they be added and/or removed mid-sprint (though we're not really using sprints, more like short development cycles).
Thanks!
I know you don't want to be changing Stories, but what about tasks within a story? What if a new task came up, or an old task is no longer valid? Can they be added and/or removed mid-sprint (...).
Yes, they can. During an iteration, a team typically gathers knowledge and gets a better understanding of what has to be done, or not. As a consequence, a team may discover that a task isn't really relevant, that a given Backlog Item requires more work than expected, that an initial estimation is wrong. In such cases, you definitely want to update your Sprint Backlog and the Burndown Chart to stick to the reality and keep what has to be done visible: you really want to know if the iteration is still on track, if you can take one more items, etc.
So, yes, don't hesitate to update, remove, add tasks as soon as you discover it has to be done. And the earlier, the better.
In our team, we use a task board inspired by Scrum and XP from the Trenches from Henrik Kniberg and we have a special location for "unplanned items" as illustrated below:
We like this approach because it makes easy to detect if unplanned items are killing an iteration. And we also "review" such tasks during the retrospective to see how we can improve our planning meeting, our estimations, the way we break down items, etc.
The team commit on user stories, not
tasks
It's not a problem to have some tasks changing as you are facing problems or have better implementation ideas.
In fact, it's very rare to finish a sprint with every task 100% "predicted" accurate in the sprint planning meeting.
They can and should change. The board should be updated at least daily.
But Pascal replied to that already - I want to make another point: from experience 'trying to adopt' Agile through small changes won't work. Scrum is a complete framework - by this I mean there is very little in Scrum (I'd say nothing) that can be dropped without doing harm to the process and promoting dysfunction or at least allow dysfunction to continue (wrote about it). Going slowly can be the only way to go in some companies/circumstances, but it has this risk that lingering dysfunctions will blow the process of change/improvement before it can reach its end and yield benefits.
I already like Pascal and Andy's answers so not to repeat.
A usefull alternative is to start a Kanban Board. Henrik Kniberg also has a good 'book' about it, available here:
http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
It allows you to organise your work and be isert some Agile thinking into the company. As Andy said, Scrum is an All-in, if not you will find that 'It doesn't work'.
Why not? Leave the space to team to complete the work the way they would like to do.
Stories are 'contract' between client, product owner and team, therefore it is good to not change, add, remove stories without letting them know. But tasks are only for team.
The team should be able to track the effort the way they need to make it visible.
Questionable is a change of hours the team commited to complete in the sprint, but good scrum master and experienced team is able to self-organize that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
In Scrum and/or other Agile methods how do you handle versions of requirements simply? I assume that there are plenty of organisations who are Agile but also need to keep a track of requirement changes for regulatory purposes and so on.
You may have a requirement in version 1 which is substantially altered in version 8. How do you track that kind of change between releases?
The simple answer is: we don't, as keeping track of the changes doesn't usually make much sense or bring any benefits.
However, if for any reason you must keep track of changes (like wasteful overhead forced upon you by "regulations" - not unheard of, right?) the best thing to do is to keep your backlog in such a way that you would be able to tell how and when it did change. This is where scrum software tools can help, as doing it with a board and index cards would be a major pain. Sometimes just a simple history of all changes to any backlog item (like what we have in our Scrum tool) will suffice, sometimes you will need more complex reporting (available in some more complex tools), and sometimes you will have to produce some additional documents.
BTW - I understand "a requirement" to mean a single backlog item, usually a user story (or epic). As such those usually don't change a lot, their position on the backlog does, but usually not the stories themselves. Recording changes of stories position on the backlog doesn't make much sense in an agile project, however recording when stories were done (keeping data about past sprints) is a good practice. Recording changes to the story itself (edits, changes of attachments etc.) would be where the Scrum tool should help you if this is what you want/have to track.
You could version your requirements document(s) right along with the source code... that way, you'd have the documents that detailed the requirements at any point in time, along with the code that implements (or attempts to) those requirements.
That being said, I don't think this is any different in "agile" or "scrum" than it is in any development process.
A wiki linked to your user stories / requirements tool is probably your best bet.
We use Assembla as our main collaboration tool for our agile projects. It has a wiki where you can document your requirements and a ticketing tool that can be easily linked to the wiki (and code check-ins) through simple tags for requirements traceability.
Both the wiki and the ticketing tool keep history, so it would be easy to view and document changes over time.
As others have mentioned, from a process perspective, it's probably better to break down your requirements / stories from epics into smaller stories and ADD new stories to capture new requirements as things progress. The tool I mentioned (and I'm sure several other tools) allow you to do this easily and link the items together if you want to see how a feature progressed or was added to over time.
Why do you need to track requirement changes (I have a lot of reasons, but what problem are you trying to solve?). Do you have the option of building your product iteratively or do you need to figure most of it out up front ?
If you are able to build iteratively, I would skip requirements version management. Individual sprint deliveries will define the product at different points in time. The next sprint backlog will define committed work.
The master backlog or wish list can change as needed. It may not be necessary to track changes as the work hasn't been committed.
If you do need more control, I like Paddyslacker's recommendation of a Wiki. Most other mechanisms don't handle the relationship concepts of epics and the break down of requirements. I have always found a single file to be insufficient for complex features.
There is nothing built-on SCRUM that resembles requirement version management. That you require it may be a sign that you are either not really implementing SCRUM or that SCRUM is not the right process for you. If I had to implement something similar I would first look into your product backlog (from which detailed sprint tasks are derived) and map stories/use cases/requirements versions to them, then I would check for updates on already released items during sprint planning to see if a new "update code to match requirement" task are required for the sprint.
(I'm avoiding talking about agile as there are hundreds of agile processes out there, perhaps somebody else can give their point of view on AUP or Crystal Clear)
You didn't mention what platform you develop on but if you use TFS; it keeps track of all changes to Backlog items, when they were changed, and by whom.
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 a dev team where we religiously follow agile.
However, I have not had to change how I work (unit testing etc doesn't count as I do that anyway). I mean, do I need to change how or how often I communicate? This soft skill side of things with agile is what I am interested in.
Thanks
If your team is utilizing agile well, then you probably should see some changes in how you work. It's possible that you already developed with a fairly "agile-compatible" mindset, even if your previous work experience was in a more waterfall-style methodology.
Some specific things that I think agile developers ought to be doing (and in a well-run agile team, will naturally find they need to do)
Focus on incremental, complete changes rather than massive architectures - This is a core tenant of agile from the macro planning side, but it's also important to practice even for an individual developer. With a 2 or 3 week iteration, you'll find you simply don't have the time to spend 1 1/2 weeks developing something, and half a week integrating it all together.
Check in early, check in often, and check in working code - Don't do this, and you'll soon find you're that guy famous for breaking the build with a day left before the iteration ends.
Know what's blocking you, and what is likely to block you in the upcoming week or two, and tell people about it - No one in an agile team likes hearing at the last second that a developer working on a critical piece is held up waiting for something to complete his work.
Think about the end of an iteration throughout the iteration - Every line of code you write should be done with the consideration of whether this is realistic to complete before the iteration is over.
Always Be Crunching (hey, I couldn't have a pithy list of advice without a cute, Glengarry Glen Ross ripped off acronym!) You'll learn by your second or third iteration that slacking off for a week followed by some all nighters is going to bite you in the ass.
If you're already following all these - great! They're certainly general best practices rather than being specific to Agile. I think most developers do have a bad habit or two that this list addresses, though (I know I do on occasion.)
In addition to Ryan's great points here are a couple more.
Discuss your ideas with other members of your team. Your fellow developers will quickly point out potential flaws in your thinking and suggest alternatives (be ready to listen and not get offended). I found this works best during planning/story tasking. In a 2-3 week sprint it is painfully obvious when you go down the wrong path. It might even stop you from successfully finishing all you tasks/stories. If others know your plan of attack up front it makes it easier for them to step in and help you out finishing your work if you need it.
Do not hesitate to suggest new ways of doing things. One of the great things about agile is that team processes are not set in stone but evolve from a series of retrospectives. If you have developers who never speak up, the process never changes and things do not get better.
Put your user's hat on. Every application has an end user. Sometimes (especially when you do not have a close contact with your users) you have to step back and question decisions (even if made by a product owner). If you can make a good case, not only your users but the entire team will benefit from it since the product will be better received. Developers do not do this often enough. We want to make things better, faster and leaner in the expense of other, sometimes more important things like delivering on time or adding more features.
I hope this helps.
The specifics of agile will be different for every person you ask. Yes, you probably want to communicate regularly, but you don't want to take it to extremes that keep you (or your coworkers) from being productive.
But like I said, it will be different for everybody. The only people who know how best to match your team are the people on your team. Just tell them you aren't used to agile and you were wondering how you've been handling it. They're really the only ones who will be able to say for sure.
Short answer but was very useful to all developers that asked me that question:
There is a book called Practices of an agile developer,http://www.pragprog.com/titles/pad/practices-of-an-agile-developer.
This book will specifically answer to your question. I like it very much because it's not just about the process, but behaviors and psychology.
Attitude-related things:
1) Good pair programming means making an effort to explain things really well and listening carefully. That's a skill in itself. You have to learn how other people tackle things and be patient when other people tackle things differently from you.
2) Being prepared to be flexible and change your mind. The smaller the ego, the easier and less painful it is to handle this.
3) To do agile well, you need to be communicating continuously with everybody in the wider team (i.e. not just devs - sysadmins, managers, customers, network admins, hardware people...) Part of this is feeling comfortable, safe and confident - i.e. there needs to be real trust in the team, not just phoney trust - real trust
4) Be prepared to work outside your specialism and comfort zone. I often have to pair with graphic designers, system admins and DBAs. Saying "that's not my job" isn't part of agile. We're part of a multidisciplinary team and getting the product released in a useful state is the whole team's problem - not just looking after my pet specialism.
5) Try to keep things simple and minimal - no "we'll make it totally generic" or "we'll need it later". Think "you aren't gonna need it." We're shooting for small, simple, concrete steps informed by feedback.
6) Tackle the difficult things and the things that aren't clear first - so that the you get feedback on the problems as early as possible so you if you have to revise estimates or cancel the work the customer gets informed as soon as possible.
7) Try to keep the team dynamics co-operative rather than competitive. Pitting people against each other pulls the team apart - and it gets you well-polished fragments and a broken product rather than a cohesive whole made by people that give-and-take as they find necessary to be successful.
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 you have sprint task in Scrum, where do you put how you want to program something? For example, say I am making a tetris game and I want to build the part of the game that tracks the current score and a high score table. I have my feature, my user story and my task, but now I want to talk about how to design it.
Is that design something that is recorded on the sprint somewhere as to how to do that or is that just somethign the programmer figures out. Do you put do task x use database such and such, create these columns, etc.? If not, do you record that at all? Is that what trac is for? I don't mean too high level design.
I touched on it here: Where in the scrum process is programming architecture discussed?
but my current question is later in the project after the infrastructure. I'm speaking more about the middle now. The actual typing in the code. Some said they decide along the way, some team-leads. Is this is even documented anywhere except in the code itself with docs and comments?
edit: does your boss just say, okay, you do this part, I don't care how?
Thank you.
There can be architectural requirements in addition to user-specified requirements that can muddy this a bit. Thus, one could have a, "You will use MVP on this," that does limit the design a bit.
In my current project, aside from requirements from outside the team, the programmer just figures it out is our standard operating procedure. This can mean crazy things can be done and re-worked later on as not everyone will code something so that the rest of the team can easily use it and change it.
Code, comments and docs cover 99% of where coding details would be found. What's left, if one assumes that wikis are part of docs?
Scrum says absolutely nothing about programming tasks. Up to you to work that out...
Scrum doesn't necessarily have anything explicitly to do with programming - you can use it to organise magazine publication, church administration, museum exhibitions... it's a management technique not explicitly a way of managing software development.
If you do extreme programming inside scrum, you just break your user stories for the iteration down into task cards, pair up and do them.
When I submit tasks to my programming team, the description usually takes the shape of a demo, a description on how the feature is shown in order to be reviewed.
How the task will be implemented is decided when we evaluate the task. The team members split the task in smaller items. If a design is necessary, the team will have to discuss it before being able to split it. If the design is too complex to be done inside this meeting, we will simply create a design task, agile/scrum doesn't force how this should be done (in a wiki, in a doc, in your mind, on a napkin, your choice) aside for saying as little documentation as possible. In most case the design is decided on a spot, after a bit of debate, and the resulting smaller tasks are the description of how things will be done.
Also, sometimes the person doing it will make discoveries along the way that change the design and so, the way to work on it. We may then thrash some cards, make new ones. The key is to be flexible.
You do what you need to do. Avoid designing everything up front, but if there are things you already know will not change, then just capture them. However, corollary to YAGNI is that you don't try to capture too much too soon as the understanding of what is needed will likely change before someone gets to do it.
I think your question sounds more like you should be asking who, not when or where. The reason Agile projects succeed is that they understand that people are part of the process. Agile projects that fail seem to tend to favor doing things according to someone's idea of "the book" and not understanding the people and project they have. If you have one senior team lead and a bunch of junior developers, then maybe the senior should spend more of their time on such details (emphasis on maybe). If you have a bunch of seniors, then leaving these to the individual may be a better idea. I assume you don't have any cross-team considerations. If you do, then hashing out some of the details like DB schema might need to come early if multiple teams depend on it.
If you (as team member) feels the need to talk about design, to so some design brainstorming with other team members, then just do it. About the how, many teams will just use a whiteboard and brain juice for this and keep things lightweight which is a good practice IMHO.
Personally, I don't see much value in writing down every decision and detail in a formalized document, at least not in early project phases. Written documents are very hard to maintain and get deprecated pretty fast. So I tend to prefer face to face communication. Actually, written documents should only be created if they're really going to be used, and in a very short term. This can sound obvious but I've seen several projects very proud of their (obsolete) documentation but without any line of code. That's just ridiculous. In other words, write extensive documentation as late as possible, and only if someone value it (e.g. 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
Recently, we've come across an issue at work where if one person is working on some code by themselves, it seems to come out with the other team members looking at it and going "Huh? That's ugly, unmanageable, I need to rewrite that"
In fact, recently, I myself have had to re-factor something that was written the week before so that I'd be able to add in my (related) feature.
I know that Pair programming is the way to go for this, but we have an uneven team (3 members). As our team is being pushed pretty hard at the moment, we really don't have time for Peer Reviews (though we can do Pair Programming, as we're allowed to estimate that into our task estimates)
I'm just curious as to how people would suggest we overcome these issues with poor code being generated.
When you work alone, and produce code which your colleagues find ugly and unmanageable and needs to be rewritten, then do you:
(a) agree with them when you look at it a second time,
(b) disagree?
If (a), then the problem is that on your own, you aren't fully clarifying your code when you write it. Since pair programming is the only thing making you write decent code, I suppose I'd recommend that the "odd one out" should work on tasks which do not involve writing long tracts of bad code: bug-hunting; maybe writing test code, since that tends to be a bit less fiendish. Meanwhile, work on improving your skills at writing better code - perhaps do reviews of your own code from a few months ago, and make notes as to what was wrong with it.
If (b), then the problem you have is incompatible ways of expressing your ideas. The code may not be bad by your standards, but it's mutually incomprehensible, which in a corporate setting means it's bad code. Pair programming means what you write is a compromise that 2 out of 3 of you understand, but that's not really a solution. You need to come to some mutual agreements about what you find most difficult about each other's code, and stop doing that. And you all urgently need to start thinking of "code quality" in terms of "my 2 colleagues will like this code", not "I like this code".
Either way, you all need to work on writing code for the purpose of being read, rather than for the purpose of getting the immediate job done as quickly as you possibly can. Personally I have done this by trying to express things in the way that I think other people might express and understand them, rather than just what makes sense to me at the time. Eventually it becomes habitual. When I write code, I write it for a public audience just like I'm writing this post for a public audience. OK, so on my personal projects it's an audience of people who think just like me, whereas at work it's an audience that thinks like my colleagues. But the principle is to write code as if someone's reading it. You're explaining yourself to them, not the compiler.
Not that my code is the best in the world, but I do think I benefited in that my first job was in a company with 30-odd programmers, so I got to see a wide range of ways of thinking about things. Also a few examples of "what not to do", where one programmer had done something that nobody else could easily understand, and therefore could definitively be said to be bad. With only 3 people, it's not clear whether a 2 v. 1 difference of opinion means that the 1 is a freak or a reasonable minority. When I did something and 4 or 5 people could glance at it and immediately say "eeew, don't do that", then I started to really believe it was just a dumb idea in the first place.
I'd also recommend that if you aren't allowed to budget for code review, lie and cheat. If you're heavily re-writing someone else's code, you're effectively taking the time to review it anyway, you just aren't providing the feedback which is the worthwhile part of code review. So sneak the review in under the radar - write a function or three, then ask a colleague to look at it and give you instant feedback on whether it makes sense to them. It helps to have a conversation as soon as you've done it, with the code on the monitor, but do try not to interrupt people when they have "flow", or to get into lengthy arguments. It's not pair programming, and it's not formal code review, but it might help you figure out what it is you're doing on your own that's so bad.
I'm surprised that you don't have time to do peer reviews but you have time to do paired programming. Is the latter not a much bigger sink of time?
We also have three developers only at our company and, surprise, surprise, we're being pushed hard at the moment. I'm pretty sure my boss would laugh at me if I suggested paired programming because that would be viewed as doubling the number of man hours for a task even though in practice that's not the result it should produce. Our peer reviews are never more than an hour and that is an extreme case. On average I would say they are probably about 10 minutes and, per developer, only happen once or twice in a day.
IMO you should give peer reviews a try. You often find that the offending people (i.e. the people writing the lower quality code) eventually realise that they need to make more of an effort and the quality improves over time.
If you have three developers and each of you think the others code is not good, you urgently need peer reviews.
So:
you are being pushed pretty hard
your code is of poor quality
Do you think the two could possibly be related? The answer is to fix the schedule.
Pair up all three at once.
Set up some coding standards.
Use a dunce cap for build breaking developers.
Perform daily stand up meetings to communicate progress.
Also try peer reviews twice a week, like Tuesday and Friday.
Pair Programming doesn't have to be all day every day to be effective. I have seen good results from even an hour or two working together each week. One way to go would be to pair A & B for a while, then A & C, then A & B... with a lot of individual time in between.
It also depends a lot on the personalities and chemistry of the team members. Two of the three might work exceptionally well together and you'd want to benefit from that.
You should still pair. Set up sessions say 1 day per week and rotate the pairs. This should keep your manager happy and increase the quality of the code, improve communication. If you keep metrics on how many faults happen in paired vs solitary coding you should start to see the benfit and display this to your manager,
eg This took x man hours but saved on average y in defect fixing. Additionally the clode is cleaner and will take less time to alter then next time we touch it.
From there you will have hard statistics and you can start to code more.
Basically your story seems to be the same as mine.
No time to do things.
Mistakes happen.
Rush to fix it (taking more time)
Go to 1
You need to stop the rot.
Code reviews
Enable Stylecop that will force you to write readable, standardised and manageable code
We use code reviews. Additionally there are some single task: changing a diagram, installing some stuff...