FAQ

Rationale

Why did you write (yet another) Scrum Tool?

I developed Scrumpy to see if I could build the tool that I needed to have. All I wanted was a simple and robust application that would do a better job of maintaining a Product Backlog than a Spreadsheet, wasn't cluttered with unnecessary features and didn't try and interfere with existing Scrum practices that work just fine as they are. Also, I felt that there was an opportunity to derive meaningful and useful forecasting information from the Product Backlog which did not seem to be well catered for in even the commercial tools available. Scrumpy is the platform on which I could test these ideas.

Why not just use a Spreadsheet?

I used Spreadsheets for years and this was okay at first. After a while I found that the Product Backlog of even a modest software product became large and complicated and maintaining this information in this way became manually intensive. There came a point where using a Spreadsheet made it harder to derive the information that I needed. Unlike a Spreadsheet, Scrumpy is a 'Scrum shaped' container for your Product Backlog built on a simple and coherent model of the Scrum process. Because of this it does a better job of helping you to maintain the Product Backlog and adds value by making the information contained within your Backlog accessible for less effort.

Why not use a Commercial application?

Well, obviously you have to pay for them and in my experience mature commercial tools drag around the legacy of having to be all things to all people. Years of competing with each other on feature set together with the shifting fashions in our industry tend to make them overly complex and somewhat incoherent. Scrum is a lightweight process. An effective Scrum tool doesn't actually need to do that much and shouldn't need to cost anything.

But it doesn't have any "Task Management" features?

No. I believe that the best place for task level planning and tracking is face-to-face at the Scrum Board or anywhere but not in an electronic tool that encourages people to think that they no longer need to talk to each other. The goal of Scrumpy is to provide features that compliment existing practices and not encroach on areas where a more effective solution already exists. In addition to there being no concept of a Task Scrumpy will never have the concept of a Team Member.

Why isn't it a Web Application?

Maintaining the Product Backlog and making it visible to interested parties are two different activities.

Capturing and maintaining the Product Backlog is typically the responsability of one person (usually the Product Owner). Even if you have a Product Team there will probably only be one person actually capturing and maintaining the backlog. This activity benefits from a robust, performant rich client interface.

In my experience there are actually relatively few stakeholders who take an active interest in the contents of the Product Backlog. These would typically be the Client, Management and Scrum Masters and the interactions between these parties are necessarily mediated by the Product Owner. Although of course it is helpful for the Product Backlog to be visible to these people (who may be somewhat dispersed) this visibility is not a substitute for regular, proactive, face to face interaction. Scrumpy publishes the content of Product Backlogs onto the Intranet allowing those people who wish, to see the current state of play. This content can be printed and used as a basis for the stakeholder discussion described above.

Finally, I am not comfortable entrusting something as important as the Product Backlog, our Agile Plan on which we depend totally to a third-party off in Internet land. Personally, I prefer to use a tried and trusted, robust, locally installed application that does just what I need it to do well, and only changes when I update it.

But what about my Offshore "Team Members"?

Distributed teams require the kind of investment and committment that most organisations aren't prepared to entertain. Lets face it, few organisations know how to run a team of co-located developers effectively let alone one distributed across multiple timezones. I have yet to see any material benefit from distributed teams (no matter how cheap Offshore "resources" appear on paper to the Bean-Counters of this world) and firmly beleive that the most productive and cost effective teams are highly skilled, disciplined, small and localised. If you must have Offshore developers make them into a whole team, invest in bringing them up to speed with the process and have them pull Stories from the Product Backlog just like your local teams. Generally it is my experience that distributed teams are in practice more of an Organisational Impediment.

Configuration

How do I find out if there is already a program using port 8080?

The following Windows command can be used to determine if port 8080 is in use:

netstat -ao | findstr 8080

If the port is in use it will produce something like this indicating that process id 576 is listening on the port.

C:\>netstat -ao | findstr 8080
  TCP    YourHostname:8080          YourHostname:0             LISTENING       576

You can then use the netstat -a command to list all the ports that are in use (and pick one that isn't).

How do I change the Scrumpy Webserver Port?

Scrumpy's default webserver port is 8080. If this is already in use on your machine you can specify another port by editing the scrumpy-x.y.y/cfg/scrumpy.properties file and assigning an alternate value to the jetty.port property.

How do I change the Story Point numbering Scheme?

By editing the scrumpy.storySizes property in the scrumpy-x.y.y/cfg/scrumpy.properties file. See below:

# The default Geometric Story Size Scheme
scrumpy.storySizes=XS=1,S=2,M=4,L=8,XL=16,XXXXL=128
# For a Fibonnaci Story Size Scheme use the following line instead: 
# scrumpy.storySizes=XS=1,S=2,M=3,L=5,XL=8,XXL=13,XXXL=21
# Or even like this if you prefer not to use the T-Shirt sizes:
# scrumpy.storySizes=1=1,2=2,3=3,5=5,8=8,13=13,21=21

Note that this is presently an application wide setting. If you want to change it then it is best to do so before you begin entering User Stories. Otherwise the size and associated Story Points for existing Stories will not be as expected and you will need to edit all your existing stories to the size you require under the Story size scheme you have defined.

How do I change the Scrumpy's Look and Feel?

Scrumpy ships with Substance and Looks each of which have offer a selection of Swing Look and Feels (LAFs) which may be more to your preference. You can select the desired LAF by setting the -Dswing.defaultlaf property in the appropriate launch script for your platform to the fully qualified class name of the LAF e.g. "org.jvnet.substance.skin.SubstanceOfficeSilver2007LookAndFeel"

  • If you want to use a non-Substance or Looks LAF you will first need to copy the jar file(s) for your LAF into the scrumpy-x.y.z/bin directory.
  • Edit the value of the -Dswing.defaultlaf property in the scrumpy.bat or scrumpy.sh files in the …\scrumpy-x.y.z\bin directory to the name of your Look and Feel.

Getting Started

How do I import the User Stories from my Spreadsheet?

To help get you started with Scrumpy it is possible to import the User Stories of your Product Backlog into the application as a CVS file.

  • First you need to have created a Portfolio and a Product.
  • Select the File|Import|Stories menu option.
  • On the Import Stories Dialog select your target Portfolio and Product, browse to the .CSV file containing your stories and click the Continue button.
  • Scrumpy will attempt to read and validate the Stories in your file. If there are errors they will be shown in another information dialog so you can fix the problem. Otherwise you will be asked for a final confirmation and the files will be appended to the selected Product's Backlog in the order (i.e. priority) in which they were read from the file.
  • You can then assign the Stories to Releases and Sprints as you wish.

The file format is as follows:

  • No header row
  • Fields are:
    • Name : String (1-64 characters) required
    • Date Added : Date (DD/MM/YYYY) required
    • Story Points : Integer (0 to 999) required
    • Description : String (1-1024 characters) required
    • Done Date : Date (DD/MM/YYYY) optional
    • Product Name : String optional
    • Release Name : String optional
    • Team Name : String optional
    • Sprint Name : String optional

Here is an example:

"CSV Story File Import","12/06/2009","4","As a new Scrumpy User I want to be able to import my existing Product Backlog items into Scrumpy from Excel so that I can see them in the charts, and use it as the baseline for velocity projections without having to enter them all manually.

Acceptance Criteria:
1) Able to import around 300 stories with ease.
2) CSV file format
3) Fields: Name, Date Added, Story Points, Description, and Date Done (if applicable).
4) File format validation
5) File import error view.
6) Handle multiline descriptions with commas in correctly.","14/06/2009","SCRUMPY","1.3.2","ME","Sprint VIII"

Additional Notes:

  • All dates must be in the past.
  • The Done Date must be after the Added Date.
  • Strings can be quoted and contain commas and newline characters.
  • No Stories will be imported if there are any errors in the file.
  • Tested with CSV files from Excel and Open Office.
  • Since release 1.4.3 exported Stories can now be imported back into Scrumpy. If the Release Name and Sprint Name are present in the file then Scrumpy will try and assign the imported Story to the named Release and Sprint. It can only do this if the named Release and Sprint entities already exist. If they do not Scrumpy will ignore this information and you will have to assign the Story to the relevant Sprint/Release manually.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License