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
As I understand things, the Scrum backlog is composed of a series of Stories that represent something for the end user and this is further decomposed into Features.
If this is the case, where does all the behind the scenes features go that aren't really linked to a story but are still useful?
For example, say I'm making an application that catalogs the contents of a hard drive. A story wouldn't require it but having an md5 hash on each file would be a nice feature for flagging duplicates.
The classic template to write good stories is: "As a <role>, I want to <action> so that <business value>" (or variations around this) and a story should indeed provide business value. Why? Well, if a story does not communicate the business value it generates, how could a (very likely non technical) Product Owner evaluate its importance and prioritize it accordingly? Writing good stories increases your chances to get them rated as important and thus implemented.
A great tool to find good business value is the 5 Whys (which is used for root cause analysis, i.e. finding the root cause of a problem). The cucumber documentation explains very well how to use it to find some "good" business value and has a very good sample, so, instead of paraphrasing it, I'm quoting the explanation below:
Business value and MMF
You should discuss the "In order to"
part of the feature and pop the why
stack max 5 times (ask why
recursively) until you end up with one
of the following business values:
Protect revenue
Increase revenue
Manage cost
Increase brand value
Make the product remarkable
Provide more value to your customers
If you’re about to implement a feature
that doesn’t support one of those
values, chances are you’re about to
implement a non-valuable feature.
Consider tossing it altogether or
pushing it down in your backlog. Focus
on implementing the MMFs (Minimum
Marketable Features) that will
yield the most value.
Here is an example taken from an IRC
chat session in #cucumber:
[5:08pm] Luis_Byclosure: I'm having problems applying the "5 Why" rule, to the feature
"login" (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login
in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy: Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno... why?
[5:12pm] aslakhellesoy: I'm asking you
[5:13pm] aslakhellesoy: Why have you decided login is needed?
[5:13pm] Luis_Byclosure: identify users
[5:14pm] aslakhellesoy: Why do you have to identify users?
[5:14pm] Luis_Byclosure: maybe because people like to know who is
publishing what
[5:15pm] aslakhellesoy: Why would anyone want to know who's publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs
to someone, then the content is trustworthy
[5:17pm] aslakhellesoy: Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and
consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy: :-)
[5:21pm] aslakhellesoy: Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy: There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase
de revenues.
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy: In order to drive more people to the website and earn more admoney,
authors should have to login,
so that the content can be displayed with the author and appear
more trustworthy.
[5:23pm] aslakhellesoy: Does that make any sense?
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy: It's easier when you have someone clueless (like me) to ask the
stupid why questions
[5:26pm] aslakhellesoy: Now I know why you want login
[5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything
[5:26pm] aslakhellesoy: And if I was the customer I am in better shape to prioritise this
feature among others
[5:29pm] Luis_Byclosure: true!
So, let me start: why would it be nice to have a md5 hash on each file (which, expressed as you did, is an implementation detail and doesn't communicate any business value)?
There is no "scrum" backlog, only
Product Backlog by the product owner that has Business Values
and
Sprint Backlog by the scrumaster/developpers which list tasks traced back to a story.
I am updating for precising the distinction between a Vision Document and a Product Backlog as for Business Value:
Business Vision Document (Strategic Level) are all about Business Value as well as Product Backlog. But Product Backlog is equivalent to Functional Specifications in other traditional methodologies that is it is something CONCRETE or OPERATIONNALLY directly implementable by the team not just a VISION from a high level managing director.
Of course product backlog itself should be tracable to Vision Document Items.
At the end of the day, agile is about doing what works for you to be productive. These kind of answers are for you to decide what works.
It may just be an implementation detail of another story, or it may be a story unto itself.
What ever makes your group most productive is what it should be.
I would place them by something like:
"Non user-stories" or "NUS"
"Programmers Only" or "PO"
"Behind the sences" or "BTS"
Followed by a short description of the feature.
So:
BTS: catalog filesystem
PO: find file type with magic bytes
Strange! I'm making the same application! :-)
Update:
So, I read wiki, I think we need an extra log (the Sprint backlog).
Wiki says:
Sprint backlog
The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list.
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 does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for a team building / training activity for some of my scrum teams. I want something that really illustrates the flexibility that the team has when implementing stories to define the scope and complexity of the feature themselves. Most of the teams have long-term waterfall experience and are used to having a well-defined specification. I'm looking for something that illustrates the need for the team to vary the scope of what they are building themselves, dependent on the time and resources available.
I couldn't find anything at tastycupcakes.com and Google wasn't much help. Maybe someone has prepared something themselves they would care to share?
Edit (in response to request for example in comments)
Suppose the team has committed to building a story for displaying data to a user in a paged list for analysis purposes. The acceptance criteria can be fulfilled easily but a differnet implementation might provide added functionality e.g. wrapping a third party control which has built-in sorting and grouping functionality.
The point is, because the scrum time window is absolutely fixed the scope of the implementation may be pushed if the team feels they are ahead of schedule, especially if some technical designs proved less problematic than thought. Conversely, if some tasks have taken longer than anticipated, the team can short-cut the user story while still making sure what they delivers satisfies the acceptance criteria.
The thing I am trying to get away from is the current mindset that the feature has a specification set in stone, and that's what will be built, whatever the circumstances.
I don't think it is up to the team to define the scope and complexity of a story. It is the PO's job to define the conditions of acceptance and then it is the team's job to estimate size based on the PO's description. If the stories are right sized, the conditions are usually pretty tightly defined. This could be why you aren't seeing much out there ....
EDIT:
I don't think your example changes my answer. If the PO wanted this "additional functionality" such as sorting etc, they would have defined it in the story or in another story. To build something that isn't asked for is waste. Spending time on a story that is low priority in the backlog is inefficient. Agile is based on building what is needed and only what is needed in order of importance. So I would frown on developers adding "extra goodies" just because they are working on a particular screen.
That does not mean you shouldn't look over all the stories in the backlog and make architectural plans based on what will be needed in the future.
I think I get what you're looking for, but feel free to clarify if I'm mistaken. I'm under the impression you're looking for an exercise that will show the flexibility in implementation details the team has when using user stories.
If so, try an exercise like this.
Split the team into two groups and have the same Product Owner between them (or you can have one Product Owner for each group if both PO's know the exercise).
The PO presents a fictional story like, "As an executive at BigSales Co, I want to be able to see, at a glance, which salespeople are performing and which are not, so that I can pair performers with under-performers to improve the overall team performance."
A story like the one above is light on implementation details, but has a very clear business problem to be solved (as user stories should). Using a story like this, give the teams 30 minutes to work on a paper prototype that would satisfy the user story. They can interact as much as they want with the PO during this time frame. The person playing the PO should be careful not to give them implementation details, but leave it to the team to decide, while expressing and clarifying the business need.
At the end of the 30 minutes, have each team present their solution and explain how it satisfies the user story.
The important thing here, is that once both teams have presented, it is likely that both presentations will be quite different and yet both valid. This shows the level of flexibility the team has to provide what they feel is the best solution without having to be told explicitly what to do.
Hope this helps.
In order to estimate the story cost the team will be expecting to work with the PO to define, in at least broad terms, the requirements for that feature. In the example you gave the team may explicitly ask the PO if the sorting & grouping functionality is needed. If they say no, as the PO can't see a use for it at that stage, then the estimate is given on that basis and the implementation done according to that. No consideration is given to these additional features on the YAGNI principle. If the requirement for the sorting & grouping comes up subsequently as a result of people using early incarnations of the product, well, that's another story, and is estimated & scheduled into the backlog accordingly. The scope of the implementation of a story isn't changed just because you've got some time left in an iteration - instead you simply pull the next prioritised item from the backlog and get on with that.
Of course, when implementing the story the team are at liberty to use the most time/cost effective method that they consider suitable for the evolving product. If this means using an component with additional capability i.e. a superset of the features then they could do so (unless this is in breach of non-functional requirements), as long as the acceptance criteria are passed, but they shouldn't go deliberately adding in unrequested functionality just because they've got some time spare in an iteration.
My opinion is somewhere between your description of adapting the features to the time, which is left, and the "just fulfill the acceptance criteria and that's it" POV of the two other commentators...
In my point of view, you all should recall the formal setup of an user story:
As a -role- I want -feature-, so -aim-.
Given the purpose of a desired feature, the developer can better understand, what the PO really wants. He then can come up with additional ideas and ask the PO, e.g.:
Hey PO, if you want -aim- so why don't we do -alternative/addition to feature-. Wouldn't that be even better?
And the PO may agree and the story is implemented as described, but in another interpretation, or the story maybe adapted. The points that is important to me:
The PO describes the purpose, he would like to have fulfilled, and a feature that is appropriate to do so
The team does not just implement the acceptance criterias like development zombies, but they are open minded and are tuned to the PO's vision in general and the single story purpose in particular - so they may come up with additional/alternative ideas.
The team also does not enhance user stories or over-engineer on their own authority. That's wasteful!
I hope you share my opinion ;-)
A good training exercise and a fun team building exercise is to do the XP Planning game.
The premise is that the product owner gives requirements for something visual (like a coffee machine, a robot) and all requirements must be drawable. The developers have to draw the requirements.
There are several short iterations (the whole exercise takes between an hour and 90 minutes depending on setup time) and it's interesting to see how communication improves and trade-offs happen as the game progresses. I've ran this myself during project kickoffs and when converting teams to agile practices and the team has always found it useful and fun.
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
So we start Scrum today and start going over story points estimates.
The first story that comes up is a new screen that needs to be developed. It has 1 sentence to describe the screen and 3 user acceptance tests.
This starts a fight between the development team and the product owner.
Product owner says that stories do not need to be speced out and they will just be fleshed out during the sprint.
We say that the story needs to be completely speced out for the sprint.
But now I am starting to be unsure about who is right....
Any good articles on this that I can send to the team about how defined a user story has to be?
What happened during sprint planning?
It appears that you did not review the sprint plan to see the stories in advance of starting the sprint.
That's okay.
Stories are fleshed out during the sprint. That's the point. Relax.
Flesh out the story quickly, build quickly.
At some point, the one sentence story may become rather complex. If that's the case, break it up into something you will finish during the sprint, and stuff you will not finish. It's okay to have some stuff that was not known and did not get built.
Relax.
Do not overspecify everything. Do not specify every nuance of the story before the sprint. Just build something that will work. As quickly as possible. That's why it's called a "sprint".
Don't build everything you imagine. Build enough that the story can be performed by the user.
The point is to build something that works on schedule. If you have to adjust the scope of the story, that's okay.
Any good articles on this that I can send to the team about how defined a user story has to be?
A story is typically made of one sentence based on the following template: In order to <benefits>, as a <role> I want <action> (and I like to add "how to demo" steps that help to understand the story and to build acceptance tests). The idea is to capture the essence, not the details. Details are captured using face to face conversation during the sprint (and may be added as high level notes to the story). But a user story is not a contract, it's a promise for a conversation (about the scenario for which the story is the title). If you need some guidelines, following the INVEST model has worked well for us.
PS: No offense but the development team seems to react very defensively (asking for full speced things sounds like "hey, we did it as it is written", i.e. CYA). A user story leaves some space for creativity. Isn't that nice? If you need more details, take your responsibilities, go gather them. And if for any reason you can't get required clarifications or details, raise an impediment and have your ScrumMaster work on it. Personally, I enjoy having some space for creativity.
IMHO fighting is not good - Product Owner, Scrum Master and Development Team form the Scrum Team so they need to work together. They want to achieve the same thing - building a great product.
To me the question is how important it is for the Product Owner how the end result looks like. If he says: "We hired the best people on the market, you're the experts, whatever you come up with is fine with me as long as the user need is fulfilled", then I'd fine with the PO statement. But of course he can not complain afterwards that he does not like the look or the colors!
Another point is that the team needs to be confident that they can commit to this story. Usually teams estimate story size with planing poker so if the development team can not estimate, you need to invest time before that you can estimate (e.g. talking about the story before, spiking and negotiate with the PO about the story). Sometimes the designer/UX guy needs to work ahead and create mockups for the upcoming user stories.
It's always about finding the balance between planning and doing :-)
fs
I believe Martin Fowler's blog post on Conversational Stories probably answers your question best. You really don't want to be in a situation where the Product Owner is required to spec out everything in detail. You've got a team of smart, creative people that are perfectly capable of making good implementation suggestions as well as asking the right questions as they come up during the sprint. You don't want to lose out on that creativity and input by locking down requirements up front.
The story should be clear enough that the team understands what the feature is and small enough that the team can complete it in one sprint before it is added to the sprint backlog. The rest of the details should be handled via conversations during the sprint.
In our practice we do internal investigation of tickets for the next spring before planing with stakeholders. We usually find a lot of questions to clarify. If we don't answers before sprint starts we can't estimate it. If we found new issues/question during sprint we inform stakeholders and usually such story will be transferred to the next ticket.
So, my answer will be: the story don't need to be completely speced out for the sprint. But team need to know all answer to questions required for implementation as well as business decisions.
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
We use Scrum. We are experiencing problems during sprints when we find the user stories are not sufficiently granular to capture the effort required to complete the sprint.
In particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons). This leads to the burndown chart looking like everything is completed on the final day of the sprint.
We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little and break them down into tasks, estimating the hours for each to create the burndown chart. During this day it doesn't feel like we have time to meaningfully improve the quality of the stories.
How best to break the cycle of incomplete / insufficient stories for our sprints?
Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?
So are you saying that:
Customers/users talk to project team
Project team writes stories and creates wireframes
Development team breaks down stories into tasks and estimates
Is there a possibility of the development team actually talking to the customers/users? User stories are sometimes seen as a way to kick off a conversation, as opposed to requirement documents/specifications.
EDIT: Some links:
A user story is to a use case as a gazelle is to a gazebo
Six Features of a Good User Story - INVEST Model
The Customer is Always Available
EDIT: Martin Fowler made a blog post yesterday on ConversationalStories that covers this far better than I did.
Are you running sprint retrospectives? At the end of the retrospective you should have high priority actionable items to improve on what happened in the previous sprint. The same things shouldnt be going wrong repeatedly.
Is your product owner accessible during a sprint? If not you may need to add extra to any estimation as the detail of a user story is incomplete.
#Pascal suggestion to dedicate 5% of your sprint to product backlog grooming is a good one. This should enable the user stories to be in a more detailed place before the start of your sprint.
We spend the Monday at the start of
each 2-week sprint going over the
stories as created by the project
team, during which time we typically
refine the stories a little and break
them down into tasks, estimating the
hours for each to create the burndown
chart. During this day it doesn't feel
like we have time to meaningfully
improve the quality of the stories.
It sounds like this is your sprint planning session, do you have control over what user stories you are commiting to complete during the sprint? How can you commit if you dont have sufficient detail?
This takes you back to having a good retrospective and solving the issues raised.
How best to break the cycle of
incomplete / insufficient stories for
our sprints?
Retrospectives, planning, backlog grooming.
Is this a failure of the project team
to nail down the stories sufficiently
at the outset, or should we (i.e. the
dev team) take some of the
responsibility?
Its the responsibility of the team as a whole. Finding blame isnt going to give value, but everyone taking responsibility will give everyone a chance of completing the project succesfully.
Maybe during those Monday morning planning sessions you can involve whoever is writing the user stories / wireframes and work together to find out what detail is missing from them, what detail would make your estimations easier and more accurate. Maybe a template of what they should include could be drawn up.
We had (and continue to in some respects) this same problem. I think this problem is a lacking of upfront analysis and a lack of devs spending enough time estimating a user story.
You might start with a story like:
As an administrative user I can create a new widget.
OK, what does that mean? After some analysis, it might mean:
As an administrative user I can create a new widget in created status with complex data validation errors.
So after that a listing of fields, how big, and what the required fields are for saving to the database. A basic UI mock up would be nice as well.
Another user story for the next sprint might be:
As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.
Then list of the complex validation rules.
We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little.
At the start of the sprint, the stories should be READY. If you need to refine them a bit, I think that you (the dev team, the ScrumMaster, the project team) should do that a bit ahead, during the previous sprint.
How best to break the cycle of incomplete / insufficient stories for our sprints?
You are maybe underestimating stories or they are too big and too vague. In both case, this sounds like an estimation problem and a good way to improve is to reduce the size of stories. To work on this issue, you could dedicate some time (e.g. 5% of every sprint) to Product Backlog Grooming in order to prepare the most important stories and reduce their size by putting them on diet if required before the next sprint. And this will actually make the sprint planning meeting smoother.
Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?
The responsibility isn't that important IMHO (except for political reasons maybe but they do not produce much value anyway), both the dev team and the project team are working together and "failing" together. What is important here is to inspect and adapt to remove the obstacle. So, it's the dev team responsibility to make this problem visible (it is an impediment). And it's the ScrumMaster responsibility to work on this impediment. The failure would be to not work on it. Backlog Grooming sessions are one way to do it. And at the end, I'm sure the project team will improve and get a better understanding of what the dev team is expecting. And you will both produce better results.
Lots of good ideas here already on the scrum aspects of your problem. Based on your comment:
particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons).
I also have a concern that you might need to work on you development process as well though. Accessing functionality from multiple locations in a UI should be a simple addition that consumes almost no time at all. If you are finding this to be a common problem then your functionality is too tightly coupled to particular UI elements. Your team might need to improve their design skills (eg: pattern usage).
This is interesting. It would appear that you are doing the sprint planning in the sprint? And that the Sprint Backlog is committed before the Sprint Planning? If so, how are the team commiting to the sprint backlog without discussing the details of the stories?
An alternative approach could be to make the Product Owner aware that certain stories cannot be added to the sprint backlog due to lack of clarity. In particular that the acceptance criteria are not fully understood. This could provoke the necessary conversation with the Product Owner. Ideally it shouldn't come to this. It should be discussed and resolved in the retrospective.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have an information theory question about how to prove (or at least give statistical evidence) that an auction website is not shilling its users.
We recently launched a pay-per-bid auction website. It is a new type of auction where the users pay to bid on timed auctions. Each bid raises the price and increases the time of the auction. The last bidder when the time runs out gets to buy the item.
The problem is that users are suspicious that we may be cheating them. I have no such intentions as the trust of my users is of paramount importance to me. However, the model could be implemented by other unscrupulous sites and it would be straightforward to cheat bidders. I need to put measures in place that will show our users that we are legitimate.
I am committed to running an honest operation. The challenge is how to prove this to the world? Any approach will need to be balanced with preserving the privacy of users.
Some ideas I have are:
show IP address of each user
solicit testimonials from winners who
have received their merchandise. Have
them mail in photos of them with
their merchandise and a recent cover
copy of their local paper.
show some broad information about each user, such as home state and country
I am looking for any suggestions.
Update
Some great suggestions. So far:
Provide behavioral information about each users:
when joined
which auctions took part of
stats for auction - bids placed, cost
do not publish personally identifiable information. No IP address, since people who did not win could exact retribution on the winner.
public forum for discussion and address questions
solicit testimonials from users to show that people do win and do receive products.
how can we show in the testimonial that it is not "invented" by us? I am thinking of perhaps asking to include a photo with a recent local newspaper. This would be hard to fake on a large scale, and how distribution of winners through time and locality.
Do you believe it would be OK to show the home State and Country of user, or would that be too much personal information?
Provide as much information as possible to users, such as who won, how much was paid, how many buys/sellers a user has made, etc;
Provide a feedback mechanism on individual auctions and users;
Have a public forum for discussion on results, support issues and complaints by users;
Don't require users to use other pay services you provide to get results, such as your own snipe system;
State your policies clearly on your Website. This should include, at a minimum, a privacy policy, discussion of how the site works, an FAQ and steps you've taken to prevent any appearance of impropriety or conflict of interest (eg employees aren't allowed to participate); and
Have a complaints and dispute resolution mechanism.
This isn't a technical problem. It's a social problem. The only way users are going to feel confident in the results is with transparency and professionalism.
Isn't that something like swoopo.com?
It first and foremost must be designed well and look professional enough that people will trust it. People are remarkably good at detecting a poorly designed website and will not respond well to it.
This may be a hard market to get into since there are such well established alternatives, but the best way to gain users is by word of mouth from existing users. This takes time, but is most effective.
Don't go violating people's privacy and publishing their information jsut because they use your site. People won't like it and won;t come back.
Provide a feedback system for users (a la ebay) where people can see other real people that are pleased with the service.
Also a public message board for comments and complaints would help comfort people as well. Good Luck!
Be ware of providing too much information though, depending on your site, your users may decide that they do not like it when too much privacy is revealed to others when they bid on something. For example, if I'm a customer and I just purchased something expensive, I do not want my user name or email shown to other people who'll start spamming me to buy a cheaper version of what I just paid for. Some others may take offense at being out bid and grief the person who out bid them by running a DOS on their IP, for example.
Yes you should protect your own site's reputation, but if you do not take actions to protect your users, you may end up losing some of them.
I think the best way to improve your reputation is through usage (may be hard), or through some reputable review sites.
Giving out IP addresses of users might be risky, and ultimately it's something that a fake site may fake as well.
I guess one way of gaining trust is to use a trustworthy authority to approve you. IOW, delegation :) let someone else solve the problem for you. e.g. Users will tend to trust you more if you're backed by someone like PayPal. That would cost you, though.
[philosophical]
The main problem is that in order to gain trust you need to provide what sociologists call "honest signals". And honest signals are usually costly. That's a problem in business because it means you have to sacrifice your earnings in order to get more customers on-board, and then balance that equation. IOW, customers and shareholders have different incentives. But as a "starup" trying to gain the trust of a user base it would make sense to signal your honesty by costly gestures. You might make less money initially, but eventually, once you're big enough, that signalling would no longer be necessary.
So what kind of honest (costly) signal can you send? Well, maybe instead of soliciting testimonials from winners you should Pay them a symbolic fee. Make it worthwhile for users to help you prove the site's authenticity by disclosing information about themselves or the transaction, and in turn make it up for them with discounts, rebates, whatever.
Anyway, I'm pretty sure you won't gain trust by simply handing out people's information to everyone without asking them. Let people do that for you, and compensate them, thereby signalling your intentions in a costly (honest) manner.
[/philosophical]
Have real time chat on the bidding pages, like IRC. People can only bid by typing "#bid $200" or something in the chat window. That way users can interrogate anyone they think might be a bot or whatever. They can also discuss the product for sale and warn others if it's a fake listing or whatever. You need to show people they can trust the site. People trust people.
Remember sitting through a talk on use of cryptographic methods to prove various facets of auctions were conducted properly. Googling "cryptography" and "auctions" together should provide some starting material if your interested in this approach.
http://www.youtube.com/watch?v=IzVCrSrZIX8
http://www.cs.virginia.edu/crab/Auctions.ppt
Jeff Atwood talked about this on www.codinghorror.com last month.
http://www.codinghorror.com/blog/archives/001261.html
I had never heard of the concept before. He does explain it fairly well.
Cathy
You cant without lying.
The only way to win is by sheer luck. You just call your lottery tickets "bids".
Shame on you.
EDIT:
Some opinions on penny auctions
Profitable Until Deemed Illegal
Penny Auctions: They're Gambling
Open source?
This is a matter of trust and so is a social, not technical issue.
Even if you open-sourced the code and/or had an information theoretical proof, how many of your customers would understand it?
In situations like this, many companies rely on a the word of a trusted third party who has inspected the company's operations. The third party stakes its reputation on its public statement that the company is doing business correctly.