Scrum Software Tool | ScrumEdge Online

The Scrum Team Composition

2010-07-29T03:20:00.001-07:00

By Steve Miller

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

Team Composition

Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the Product Manager, CTO, in some cases the CEO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product. Before a sprint begins, the Product Owner communicates the goal of the sprint to the team and what features should be analyzed for the release. This does not mean that all the desired features will make it into the sprint, the team estimates and prioritizes items for the sprint (during the Sprint Planning sessions), and only the items that can fit in the sprint are done.
ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspections happen, and ensuring everyone plays by the rules. The ScrumMaster coordinates and runs the daily sprint meetings. The ScrumMaster is not a task master, they are a leader that empowers the team members to deliver the assigned tasks and to help eliminate roadblocks that slow them down.
The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation. The Team is responsible for staying focused on assigned tasks, soliciting help as they encounter road blocks, fully testing their code, refactoring code, logging their time daily (including estimated time remaining on each task), and for checking their code daily or more often if possible.

Our Experiences with Team Composition

In our experience, it is unrealistic to assume that The Team can handle quality assurance and documentation well. We have improved the team composition to include 2 additional roles:

Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.

6 Tips for Good Scrum

2010-07-26T23:48:00.000-07:00

by Martin Harris

I went along to the London Scrum User Group yesterday evening. For a change it was a quiet night. Christmas is around the corner so we had less attendees. Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum. After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack. So we stopped there and got on with eating the snacks and drinking the beer. So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?

The London Scrum Groups 6 Good Scrum Tips

Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
Run Retrospectives. Its very important to take actions away from a retrospective. Be realistic though, your never going to solve them all, so ask the team to priorities them. If your doing the retrospective right your product owner will be there to help with prioritization. If you find something very big lands at the top, split it down into stories. Otherwise pick one or two that the team feel strongly about and turn them into stories. Make sure these stories are included in the next game planning sessions and make it into the iterations. If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time. Commit to doing them and then deliver.
Ask your team to Pair Code. The XP technique of two programmers working on the same task. It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput. Don’t be dogmatic, let the team decide how much work should be pair coded.
Setup Self Directed teams. Self directed teams have been proven to be more efficient. We discussed the role of a scrum master in a self directed team. Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks. The scrum master does not plan or allocate tasks. The empowered team needs to work out what the tasks are and find out how to finish the stories. The scrum master should spend his efforts removing blocks for the team, checking quality. Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed. We also decided that to be empowered you need to make the team multi discipline. Include testers, user interface designers etc to remove hand off waste and increase team knowledge. With role diversity comes better decision making.
Deliver what you commit to. Another gem, it sounds obvious but is so often ignored. Delivering builds trust in the team and the process. Classic ways to miss delivery include: Failing to produce a strong definition of done. The definition should include the programming, integration, testing and setup tasks. In fact everything required to get that task ready for delivery. Another way to miss delivers is to fail to demonstrate at the end of the iteration. You may think your done, but when the product owner sees the work for the first time they may request refinement. If you have kept your product owner close then the demo is likely to be painless. No power-point slides please, only real working software in the demo! So commit and then deliver what you commit to.
Co-locate your team. The group defined co-location quite tightly. Co-location is not putting everyone in the same office. Its putting the team members next to each other in the same space. Intra team communication does not happen with the team scattered around an office. You should be able to turn around and join the stand up meeting. This closeness, speeds up the myriad of tiny important messages that pass around the team. Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea. If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry. Why not come along to the next one, we could use your input.

7 Tips for Improving Daily Scrum

2010-07-23T00:43:00.000-07:00

by Artem Marchenko

Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: "What did you do since the last meeting?", "What are you going to do until the next meeting?", "What impedes you from being more productive?". The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline - nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.
Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting.

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible - people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What's done is more of a context for the second and third questions. The real point is to figure out what's blocking the efficient work and who could help it.

7. If team talks too much to ScM, tell him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it's useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.

On-Site Installable Scrum Tool Available!

2010-06-21T04:44:00.000-07:00

Deploy to suit your environment!

To get the best of Scrum and enjoy many features of our scrum software management tool, ScrumEdge now provides an installable licensed release that can be installed on-site on your web server.

Our Scrum tool’s impressive lineup of features, including sprint estimating, sprint planning, tracking of user stories, tasks, issues, etc will be available for you to use internally. This release will be particularly useful for those companies with sensitive strategies and data that need to reside on their local servers.

Software Requirements:

PHP 5.2 or higher. Available at http://www.php.net
MYSQL 5.0 or higher. Available at http://www.mysql.com
Apache 2.x or higher. Available at http://www.apache.org

There are a number of packages that will help you get set up quicker than individual installations:

WAMP (Windows) - For more information, visit http://www.wampserver.com - RECOMMENDED
LAMP (Linux) - Most Linux distributions come with a pre-configured LAMP server.

Detailed list of required PHP extensions:

php_gd2
php_mailparse
php_mbstring
php_mysql
php_mysqli
php_openssl
php_pdf
php_pdflib
php_pdo
php_pdo_mysql
php_sqlite
y2k compliance
expose php
log errors
report memleaks
enable dl
allow url fopen

On-Site Installable Version of Scrum Tool Planned

2010-05-26T23:15:00.000-07:00

Deploy to suit your environment!

To get the best of Scrum and enjoy many features of our scrum software management tool, ScrumEdge plans to provide an installable licensed release that can be installed on-site on your web server.

Expected Launch Date: June 20, 2010

New Version of ScrumEdge Goes Live

2010-05-13T01:13:00.001-07:00

We are pleased to announce that a new version of ScrumEdge has been released today. We have added many new features in this release and resolved some issues reported by our users.

Major Updates:

Interface: We have done away with the old interface and come up with a completely new and more intuitive interface. Among other things, you will notice that this version will give you a lot more screen space to play with. The use of bigger fonts should make text more readable and some slick progress bars will give users the ability to check out project, sprint, story and task level progress at a glance.
Projects Dashboard: We have introduced a new project level dashboard that all users will see when they sign in. This page will display all projects the user is assigned to along with a basic snapshot of the number of sprints, stories and users that are assigned to each project. Progress bars will allow users to see project progress at a glance. Clicking on any project should take users to their main dashboard.
Story and Task Efforts: More detailed Story and Task Effort level reports will allow ScrumMasters and Product Owners to follow their sprints in more detail. Users can view their story efforts under the backlog tab. Clicking on the the number of tasks for a story should give them a view of the task level efforts. Users can also view the story effort for a particular sprint by clicking the number of stories link in the sprint snapshot section on the dashboard.
No More Free Signups: Users will not be able to sign up unless they purchase a plan. A free online demo will allow users to go through ScrumEdge and see how it works. Users can take the ScrumEdge demo by clicking the “demo” button on the main page.
Google Ads for Existing Users: Existing users with free accounts will see Google ads at the top of each page. We know this somewhat effects the user experience but we gotta make a buck too. Ads can be removed by purchasing a subscription plan.
Community Feature Removed: We have removed the community feature from ScrumEdge. When we started we had thought this would be a good feature that would allow different Scrum teams interact and discuss their scrum related problems and achievements. However, this idea never caught on and very few teams were actually using the feature.

Update - New Version of ScrumEdge

2010-05-03T00:45:00.000-07:00

The launch of the newest version of ScrumEdge has been delayed is now expected to be on May 13, 2010. Once live, you will notice that this version is significantly different from the last version.

Update Details

We have done away with the old interface and come up with a completely new and more intuitive interface. Among other things, you will notice that this version will give you a lot more screen space to play with
We have changed the ScrumEdge landing page and all users will be directed to their projects dashboard once they sign up. This dashboard will give users a snapshot of all their projects with progress bars indicating each project’s progress.
More detailed Sprint and Story Effort level reports will allow ScrumMasters and Product Owners to follow their sprints in more detail without any hassle
No more free signs ups. Once this version goes live, users will not be able to sign up unless they purchase a plan. A free online demo will allow users to go through ScrumEdge and see how it works
We have removed the community feature from ScrumEdge. When we started we had thought this would be a good feature that would allow different Scrum teams interact and discuss their scrum related problems and achievements. However, this idea never caught on and very few teams were actually using the feature.

ScrumEdge Major Update Coming Soon

2010-04-20T04:44:00.000-07:00

We are set to launch a major update on April 30, 2010. This update includes some new features and a major interface update.

Update Details:

Completely new interface that will give users a lot more screen space to play with
New Project Dashboard
More AJAX
Better charts and progress bars
Sprint and Story Effort level reports for Product Owners and ScrumMasters

ScrumEdge 2.0 Released

2009-11-25T02:20:00.001-08:00

We are pleased to announce that ScrumEdge 2.0 is release today. We have added many new features in this release and resolved some issues reported by our users. Some of the major changes in this release are listed below.

New intuitive Setup Wizard

We have done away with the old Setup Wizard and built a new one from scratch. The new Setup Wizard is easier to use and has write ups for each step to assist users. Check out the demo video for the Setup Wizard to find out more.

ScrumMasters can be assigned tasks on sprints

ScrumEdge now allows ScrumMasters to be assigned to tasks in a sprint. When ScrumMasters sign in they should see a ‘Sprint' Log’ tab on their Dashboard. If they are assigned any tasks on the current sprint they should be able to report their effort on each task under the ‘Sprint Log’ tab.

New Team Member dashboard

We have changed the dashboard for Team Members so they can view charts for any sprint assigned to the project they are working on. This will allow Team Members to view a project’s details from the very beginning.

Ability to zoom charts on the dashboard

All ScrumEdge users can now zoom any chart on their dashboard. This feature is particularly useful for teams with long sprint durations.

Interface Updates

We have updated the way projects, sprints, stories, users, tasks, issues and retrospectives are added and modified. In ScrumEdge beta all additions and modifications were made through pop-up dialogs and many users reported issues when using IE 7 and IE 8. ScrumEdge 2.0 no longer uses pop-up dialogues. Check out the demo video for the Tasks page to see the new addition and modification mechanism

More AJAX – Faster Processing

ScrumEdge 2.0 uses a lot more AJAX so you will see very few post backs. This has made processing faster and should improve the overall user experience.

Take ScrumEdge 2.0 for a test drive and let us know what you think. We always encourage user feedback as it helps us make ScrumEdge a better online scrum management tool for you. You can send us your feedback at info@scrumedge.com or from our ScrumEdge Feedback page.

Coming Soon: ScrumEdge 2.0

2009-11-17T22:33:00.001-08:00

ScrumEdge 2.0 is set to launch on November 25, 2009. In this new version we have added some new features requested by ScrumEdge users and removed issues reported by others.

New Features

New intuitive Setup Wizard
ScrumMasters can be assigned tasks on sprints
ScrumMasters working on a sprint can report their time on the sprint log
New Team Member dashboard
Ability to zoom charts on the dashboard

Issues Resolved

IE8 issues when trying to edit stories
IE8 issues when trying to edit journals
Old markup editor replaced with a new one

The Sign Up Process Explained

2009-09-15T23:14:00.001-07:00

Who should sign up?

Only ScrumMasters are required to sign up for ScrumEdge. When a ScrumMaster signs up, they are set up as Administrators for their company’s ScrumEdge account. Administrators can add as many team members and other ScrumMasters as their plan allows. The basic plan available to all users allows Administrators to add up to 5 users.

What should team members do?

If you are a team member and would like to sign up, simply contact your ScrumEdge Administrator so they can add you to their ScrumEdge account as a team member.

How to find out who your ScrumEdge Administrator is

To find out who your ScrumEdge Administrator is, click on the Sign Up button on the main page to bring up the Sign Up window. Type in your company name in the selection box to see if it already exists. If you can’t find your company name in this selection box, then you don’t have a ScrumEdge Administrator yet. At this time you may sign up as your company’s ScrumEdge Administrator.

If you company name exists in the selection box, simply fill in the rest of the fields and click the Sign Up button. This will send your ScrumEdge Administrator an email with your sign up request. Once your ScrumEdge Administrator adds you as a new user, you should receive a confirmation email.

How does the ScrumEdge Administrator add a team member?

ScrumEdge Administrators can add new users, both ScrumMasters and Team Members, from the Users page. Details about adding users can be found on the ScrumEdge Help Topics page under the Users label.

Backlog Effort Section

2009-07-23T04:44:00.001-07:00

We have added a new section called ‘Backlog Effort’ under the Product Backlog tab. This section displays the following information:

Total stories in the Product Backlog
Pending stories in the Product Backlog
In Progress stories in the Product Backlog
Complete stories in the Product Backlog

This information is also displayed in a pie chart.

Stakeholder Role Added

2009-07-17T06:52:00.000-07:00

Some users recently asked that we add a new role for Stakeholders. This role has now been introduced in ScrumEdge.

How this role works

Stakeholders can't change any project or sprint related information. The purpose of introducing this role is to allow stakeholders to view all project and sprint related information, in the interest of transparency.

Stakeholders can view the following in ScrumEdge:

Burndown Charts
Burn Rate Charts
Budget Charts
Upcoming Demos
The issue log
Product backlogs
Sprint logs
Sprint retrospectives
The ScrumEdge Community

Assigning Tasks to ScrumMasters

2009-07-15T06:50:00.000-07:00

ScrumEdge now allows tasks to be assigned to ScrumMasters. Many users had requested this feature as their ScrumMasters work on actual tasks through the course of a sprint.

Before you can assign tasks to a ScrumMaster, you will first have to add them to a Scrum Team. The following steps will help you do so:

Click on the Projects link on the left to bring up the Projects page
Click theicon next to the Project you want to add the ScrumMaster as a team member to bring up the Edit Project window
Add the ScrumMaster to your Scrum Team and click the Update button

Once you have followed these steps, you should be able to assign sprint tasks to the ScrumMaster.