"Offers a requirements process that saves time, eliminates rework, and leads directly to better software. A great way to build software that meets users' needs is to begin with 'user stories': simple, clear, brief descriptions of functionality that will be valuable to real users. ... [the author] provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle. You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, [the author] shows how to organize them, prioritize them, and use them for planning, management, and testing"--Back cover.
The book User Stories Applied contains single page discussing Personas. The definition of persona from the book is:
A persona is imaginary representation of a user role.
It futher discuss definition of the persona:
Creating personas requires more than just adding a name to a user role. A persona should be described sufficiently that everyone on the team feels like they know the persona.
It also recommends to find a photo on Internet or in magazine and use this photo for persona so that everybody can clearly imagine persona working with the application.
Ok. All these ideas sound good. It can be fun to define personas to user roles but is it worth it? Is there any real or measurable quality or increased efficiency when using them?
Do you have any good examples where personas really help the development team? Do you use personas in user stories?
I have found nice article about personas in MSDN.
This can helps when there is lot of roles and when they are very complex.
The more roles you have, the more complex it is to satisfy all of them. They have different needs, values, power, etc. Having the picture sounds a bit trivial, but it really helps too.
Check this really nice video from Jeff Patton on the subject: http://www.infoq.com/presentations/pragmatic-personas
His website: http://www.agileproductdesign.com/
In an answer to the question Documents for a project?, Chris Ballance replied that "User Stories" and a "burndown chart" are the two most useful types of project documentation for a developer.
My question is, do you know of any good example[s], which I can see (for example on the internet, or in a book), of these kinds of documentation?
If possible I'd be happy to see many examples, including:
I don't find this an easy topic to Google for: I find lots written about it, but fewer demonstrations showing it.
A very good place to start as far as books are concerned is User Stories Applied and Agile Estimation and Planning both by Mike Cohn. This have excellent examples and good starting points for anyone first coming to agile methodologies.
As far as website resources they are few and far between. Probably a good place to actually start would be searching for those keywords on Google Images as many people take photos of their burndown charts and User Stories. This helped me a lot when starting. Here are some samples: Burndown Chart, and User Stories
Please note however while a burndown chart is a simple report that you run on your current story points left in an iteration, User stories are more complex than that and do require a bit of reading to wrap your head around. Start with User Stories Applied book for that.
Hope that helps!
We are just starting on a pretty big project with lots of sub projects. we don't currently use any kind of named process but I am hoping to get some kind of agile/scrumlike process in by the back door.
The area I will be focusing on most is having a good backlog for the whole project and, at least in my head, the idea of an iteration where some things are taken from the backlog, looked at in more detail and developed to a reasonable deadline.
I wonder what techniques people use to break projects down into things to go in the backlog, and once the backlog is created how it is maintained and ordered. also how relationships between elements are maintained (ie this must be done before it is possible to do that, or this was one story now it is five)
I am not sure what I expect the answer for this question to look like. I think what may be most helpful is if there is an open source project that keeps its backlog online in some way so I can see how others do it.
Something else that would get +1 from me is examples of real user stories from real projects (the "a user can log on" story does not help me picture things in my project.
Like DanielHonig we also use RallyDev (on a small scale) and it sounds like it could be a useful system for you to at least investigate.
Also, a great book on the user story method of development is User Stories Applied by Mike Cohn. I'd certainly recommend reading it if you haven't already. It should answer a lot of your questions.
I would counsel you to think carefully before adopting a tool, especially since it sounds like your process is likely to be fluid at first as you find your feet. My feeling is that a tool may be more likely to constrain you than enable you at this stage, and you will find it no substitute for a good card-wall in physical space. I would suggest you instead concentrate your efforts on the task at hand, and grab a tool when you feel like you really need one. By that stage you'll more likely have a clear idea of your requirements.
I have run several agile projects now and we have never needed a more complex tool than a spreadsheet, and that on a project with a budget of over a million pounds. Mostly we find that a whiteboard and index cards (one per user story) is more than sufficient.
When identifying your stories, make sure you always express them in terms that make sense to your users - some (perhaps only small) piece of surfaced functionality. Never allow yourself to slip into writing stories about technical details that you could not demonstrate to a user.
The skill when scheduling the stories is to try to prioritise the things you know least about first (plan for what you want to learn, rather than what you want to do) whilst also starting with the stories that will allow you to develop the core features of your application, using subsequent stories to wrap functionality (and technical complexity) around them.
If you're confident that you can leave some piece of the puzzle till later, don't sweat on getting into the details of that - just write a single story card that represents the big conversation you'll need to have later, and get on with the more important stuff. If you need to have a feel for the size of what's to come, look at a wideband delphi estimation technique called planning poker.
The Mike Cohn books, particularly Agile Estimating and Planning will help you a lot at this stage, and give you some useful techniques to work with.
Should technical items such as "Upgrade sever from v1 to v2" or "Increase startup performance" or "Refactor login module to reduce code complexity" go in to the product backlog and if so how should a non technical product owner be able to prioritize them v.s other more functional backlog items?
Should there be a separate backlog for technical stuff? Should we have a joint PO role with two persons that could prioritize functional and technical stuff on the product backlog?
Usually in the 'vanilla' SCRUM the technical tasks you mentioned will not go as separate stories.
To me the non-technical PO should not be looking at the stories like 'Upgrade the server'. It's not a business story, it is not visible to the end-user so it is difficult to prioritize if it is formulated this way. Priorities should be assigned according to the business value of the work. 'Upgrading' does not mean much. 'Allowing more simultaneous connections', 'Reducing the downtime' or even 'improving the team velocity' might provide much more valuable insight to a non-technical person. If you cannot find a non-technical description ask yourself a question about the necessity of the upgrade :)
The 'refactoring' story is even more complicated. Did you ask yourself why is it a story at all? Refactoring could be done as a task in the story but it is rarely a story on itself. So if you want to make login work better or provide more features that's a story but tinkering under the hood does not count as one. Please also note that refactoring without a business purpose could easily lead to a so-called 'gold plating'
I would suggest doing the 'upgrade' stories as a spike with the 'improve performance' and 're-factor' being the tasks for a relevant business story.
P.S. You might find a good discussion on this topic (mostly in part 3 of it) in the excellent book by Mike Cohn called "User Stories Applied: For Agile Software Development".
YAGNI (You Ain't Gonna Need It) via Wikipedia
BDUF (Big Design Up Front) via Wikipedia
UPDATE: To clarify the question, I think I can also state it this way and keep my meaning:
"In what ways do you, as an Agile practioner, find the right balance between "quick and dirty" (unintentionally risking Technical Debt while attempting to adhere to YAGNI) and over-engineering (BDUF) within each iteration?"
It seems that if you stick with the "plan, do, adapt; plan, do, adapt" idea of agile (iterations, iteration reviews) you would avoid those things by default. BDUF is just so contrary to the idea of agile estimating & planning that if you are really agile, you wont be BDUF automatically.
The purpose of release & iteration planning meetings is to make sure you are adding the most valuable features to the project for that iteration. If you keep that in mind, you'll avoid YAGNI for free.
I would very strongly recommend the Mike Cohn books on agile planning:
Update: After your clarification about avoiding YAGNI and BDUF within an iteration...
BDUF...If I felt a feature was not clearly defined before I started work on it, I would create a small "feature" or story to account for the design type portion of the work needed. So that maybe the smaller story has a story point estimate of 1 instead of the real feature's 5. That way, the design is time-boxed into the smaller story, and you will be driven to move on to the feature itself.
To avoid violating YAGNI I would work to be very clear about what the customer expects for a feature within an iteration. Only do work that maps to what the customer expects. If you think something extra should be added, create a new feature for it, and add it to the backlog of work to be done. You would then persuade the customer to see the benefit of it; just as the customer would push for a feature being done at a certain point in time.
I really like the concept in the agile manifesto that the focus should be on working software rather then on comprehensive documentation. On the other hand a part of my job is also to manage the product and as such I need a up to date version design document at all times. Some might say that the current version of the working software IS all the documentation that I need, but I need the documentation to prove that the product works as per the customers specifications, even after 10 changes to the original design.
In a previous job each and every approved change was integrated in a design document per major feature in the system. This procedure added a significant overhead to each change, since at least one and posible two word docs had to be updated, approved and signed.
At least this procedure worked in a waterfall project but now I am looking for a more agile way to document the current agreed state of the solution so I am really looking forward to hear how you handle this issue, thanks.
Edited: My issue here is how to track how come the system looks or behaves the way it does. So I have an existing system in production and the customers logs an issue that the system should do Y when X is entered. Then I'll need to figure out the current specification for that piece of functionality which might have been changed a number of times in various user stories, sigh.
A design document is essential, but a "complete description of all aspects of a system" type document, created at the beginning of a project, is not a good idea.
You will have to get away from ideas of a design for all aspects of a system that is carved in stone. You do start out with a design and then start breaking that down into user stories which are small concentrated tasks for the parts you will be working on immediately for the first sprint.
Aspects of the design that are being implemented later don't have to be as detailed and in the intial phases may actually consist of many user stories clumped together into a user theme. Even further out, you may have clumps of user themes grouped together into user epics. As the team progresses to later sprints, the user themes are broken down into individual user stories and the user epics may start to be broken down into user themes.
Each sprint may be considered a mini-waterfall project on its own so there will be a requirements gathering and design phase at the beginning of the sprint. This is where the design document is incrementally updated with th e new portions of the design.
This concept is covered in Mike Cohn's "Getting Agile with Scrum" presentation. I'd also recommend his books "User Stories Applied" and "Agile Estimating and Planning". If there are many of you new to Scrum I'd suggest getting Mike in to teach one of his courses to you.
Have a read of Martin Fowler's excellent essay "The Almighty Thud" about creating unnecessary documentation.
What is the difference between User Stories and Use case scenario , purpose-wise ?
Use Cases are more like a contract while Use Stories are a planning tool. Consequently, Use Cases usually outlive User Stories since they (should) serve as documentation that concretely reflects the built system.
User stories are written by the customer/stakeholder/client/user. User stories aren't very detailed and are relatively open to interpretation.
Use cases are more formal in structure and are often written by a someone on the team - requirements engineer/product manager. They are often more detailed, breaking down an interaction into individual steps, and clearly identifying pre-conditions and post-conditions such as failure conditions and success conditions.
While one Use Case can cover many scenarios - success and failure; validation errors; sub use-cases and extensions - a User Story is more limited in scope, usually describing a single scenario.
A user story is synonymous with “feature” as used in the 1990s, a marker for what is to be built, fine-grained enough to fit into modern iteration/sprint periods.
A use case provides a contextual view of what is to be built, serving to bind the organization together, among other things.
I'm going through a problem that I think a lot of others go through as well.
I consider myself to be a good programmer; I have been working with the .NET Framework since its first beta release...
Whenever I need to write a new software, I "think" about what I need to do and jump straight to visual studio, file>new project and start coding.
The obvious problem is that I always get stuck in situations like: ugh! what now? I'll have to change this and that, copy and paste code from here to there... etc etc...
I'm pretty sure I lack some process BEFORE writing code, but I'm not sure of what process it is. What would you recommend? The most significant step I've made was to write a doc first, but no flow chart etc etc...
What book would you recommend me? Video tutorials? Any resource would be great!
For me, the best technique to start coding a project is the Walking Skeleton. This technique allows developers to discover an architecture that it's fit for purpose. But before coding, I find that it's good to spend some time understanding the domain and language.
During this phase which I usually call discovery phase (this is before iteration 0) I do the following:
After these steps I start Iteration 0, in which
I know that this sounds like a lot, but I know that I get a lot in return. I might no do all of this for projects that I'm sure they'll stay small (such as 1 month project for a marketing site). Something like 2 people working for 2 months is already enough (in my view) to set all of this.
For what you mentioned in your question (disclaimer: I'm making a few thousand assumptions here) it sounds like you don't know the objective of the application. For example can you try to answer these questions to yourself?
I recommend the book Growing Object-Oriented Software, Guided by Tests to learn how to build a walking skeleton, it's has a totally amazing explanation and example (it's in java though).
I'm working with good group of very sharp developers on one of my client's premises. We are coding correctly around NullPointerException and other exceptions, so we don't have those. But when it comes to business rules we have some mistakes and find issues when already in production. Granted we have very fast paced environment, and deployment to production commanded by management team, not development one. But we passed "green light" with QA and Data Quality teams.
What are the best practices to find business related bugs early in software development process.
As a compliement to akf's answer, I would like to recommend a comprehensive guide, User Stories Applied.
I've been applying agile for a few months now on my project. However we are seeing a steady problem with our iteration burndowns. We aren't hitting zero each iteration.
The tasks remaining are QA tasks. Things like writing tests, testing, etc.
Now, there is some organizational resistance to the "cross-functional team" idea of agile. Dev's develop for single projects but Testers are shared for multiple projects. Which is quite contrary to the agile idea of Dev's and QA working together.
The fact that my tester's time is split across so many other projects is the cause of our slowdowns. The developers are testing to pick up as much slack as they can, but some tasks are still not getting done.
From what I see, I can do two things:
I'd much rather avoid doing #2, since I value the testing collaboration we're doing.
What advice do you have for my predicament?
It's a tough situation and unfortunately quite a lot of companies who try to follow Agile do not recognise it. You do not have to have a dedicated QA person - even with Agile resources could be split between different tasks. You DO need to include your QA in your progress tracking.
Yes, your progress will be slower. There is a good reason for that (you don't have enough QA resources) and you should explain it to your organisation management with figures in hand. It will help you to persuade them that some change has to happen.
Also you could move towards more automated testing and use your developers to help the testers with the test automation. This will distribute the load more evenly and will improve the quality of QA on your project
Recently we started a big project (based on RFP) in scrum. We started to write product backlog list but some questions come into our mind :
1- Because of the lack of good description,vision and details about their requirements, we should go to their office and ask them lots of question about the processes and actors (an analysis process). This process may takes a week or two for our two team members. I want to know should we put these tasks in product backlog or not? (it seems not, but how should I handle it?..It is a pre-step of finding real product backlog items)
2- I have some fundamental tasks that should be done before starting the main project backlog tasks:
making the project templates ready,
making the code architecture ready(rule of coding, using of old compoentnts,code-generation, ...) ,
How Should I behave to these items? Should I put them in product backlog list or not?
Any Idea or good resources (examples) are welcomed. Thanks in advance.
EDIT I found some good articles here and here . So all things should be started from Vision document. I think vision can comes from directly from RFP document or after doing analysis steps a little after project start up (Am I right?).
First off, keep these goals in mind.
For your situation, I would do the following:
1) Get your product owner(s) involved throughout the project, not just the beginning. I can't stress this enough. Somebody needs to own this, and guide it from a product standpoint (even if this is an internal product). Without this constant feedback and guidance, you are only fooling yourself into thinking you're being agile.
2) If scrum team members (ie, not a dedicated project manager/scrum master) are doing the work described, I would include it. If the dedicated pm/sm is doing this work, and they normally don't contribute to the velocity, leave it out (or track it separately from the sprint). My point here is to be consistent with how things normally work.
If you do choose to put them in the sprint, make sure they conform to the INVEST principles. These are the types of stories that can drag on for weeks because they don't have a good "definition of done".
My final piece of advice is to not get hung up on this and just pick something and go with it. Worst case scenario, your velocity gets weird for a couple weeks. Your true goal is to monitor progress within the project.
According to Scrum at the end of a sprint, we have to create a working solution (build, concept, code). For example, the sprint duration is 1 week, and according to priority we need to pick up an issue that may take more than one week. We are using a strategy to commit everything to the master branch and we don't use branches for issues; it's done to avoid double testing of issues. We can split a big issue into small tasks, but still, at the end of the sprint we won't get a working solution. So the only way for such an issue is to develop it in a separate branch.
Maybe you have any other ideas, propositions?
Your stories should to fit the INVEST properties. the "S" debatably stands for "sized appropriate" or "small". As in "small enough to fit in a sprint". Since your sprints are not big enough to contain some of your stories you have two choices:
In regards to how you branch (or don't branch) the code in git, that's really a personal (or team) preference. If you've got good automated testing, it shouldn't matter. If you don't, then making the story fit in the sprint will allow you to not branch, not test twice, and stick to your current process.
Does anyone know of a activities that will help a new SCRUM team brainstorm user stories?
When starting with User stories I strongly recommend User Stories Applied by Mike Cohn. This book helped me a lot. The book also contains short chapter about Gathering stories covering basic techniques:
I'm starting to add first user stories to my game backlog. My team has a rough idea of the game we want to create and we are ready to gather top level requirements. How do you do this? I mean, for example you can start with a mega epic (top level) that reads "As a publisher I want to create a game where player must feed a monster so that they spent a really fun time". Is this a correct starting point? Should we now split this epic into smaller user stories and split this user stories in smaller ones and finally in tasks? Is this "tree like" way of gathering requirements good or you usually use a "flatter" way?
Thanks in advance.
A good starting-point for writing good user stories is the book by Mike Cohn. There are also plenty of useful resources online how to write good user stories and how to work with the backlog as a Product Owner and how to involve the team to continuously keep the backlog in good shape so you can have effective sprint planning sessions, do reasonable forecasting of dates when features will be available etc.
It's always important to stay practical and experiment. Start with something and then inspect&adapt that so that you improve. This is the essence of any agile tool/framework.
If you want, start with the big epic and see how that goes.
Probably it's not worth having that epic, but rather discuss various things the player of he game can do that are more specific. These things are user stories, i.e. things that add user value throughout a whole product. A vertical slice of the system.
Some made-up examples to illustrate ideas around stories in a game setting:
Yes you can see it as a tree or more and more specific stories that are children of other stories or epics. Practically, you only care about the leaves as that is the product of working together as the team and PO to work on backlog items during sprint planning or other sessions.
Experiment and start with something and improve from there.
Where can I find a practical example on how to use Bug, Risk, Scenario, Task and Quality of Service Requirement work items?
On MSDN documentation I found this topic: http://msdn.microsoft.com/en-us/library/bb668962.aspx but it is not enough for me to deeply understand when to use one or the other.
I don't think there is a single prescriptive way of using the work items. You have to adjust this to your own process and your own needs and primarily decide what you want to get out of TFS a this particular process template.
A good place to start might be the literature on agile methodology, for example:
I'm starting a new project. And I want to do good analysis. But I don't know how to do that. What document or site should I read?
Start with the Wikipedia page on Software Design. Look through the discussion and references there. Follow any links that seem appropriate. Move on to Software Requirements Analysis and do basically the same thing. Especially look at the See Also sections. You might be especially interested in Rapid Software Development by Steve McConnell (and perhaps some of his other titles). RSD gives a pretty good overview of an iterative software development approach. If you are interested in an agile approach, you might find User Stories Applied: For Agile Software Development a good read.