Software 2020 Quick Start Guide for Agile ... - WordPress.com · Software 2020Quick Start Guide for...

!"#$%&'()*)*(+,(%(-"".(-"(/'.0(1"2($+-/(-/'(%&-("3(4"+56(,"#$%&'(&+6/-(7(

Estimate &

Groom

Software 2020

Validate &

Accept

Product Team

Product Team

Track &

Code

Quality Code and Verified Specs

Customers & Support

Customers & Support

Product Team

Requirements Backlog Stories Bugs

Organize &

Plan

Software 2020 Quick Start Guide for Agile Users (for Software Development Teams)

@ Software 2020 – All rights reserved

Last Updated April 5, 2012

Software 2020 Quick Start Guide for Agile

@ Software 2020 – All rights reserved 1

1. Overview for Agile Organizations

Software 2020 was designed from the ground up to be used on all software projects for all phases: from Waterfall to Hybrid to Agile. And more – for client projects and the Call Center. A communications hub for the entire organization.

This guide describes how Software 2020 can help your Agile software development team.

Customize Software 2020

Software 2020 is a very customizable tool. You can create a unique development process for any project with customizable:

• Practices • Workflow • Terminology • Custom Fields

Where to go for more information:

The Admin user should first set up a tenant instance for your company. See the Software 2020 Admin User Guide.

See Learn How to get the Most from Software 2020 to see more about configuration and recommendations.

Our Five Minute Overview to see how Software 2020 will help you run an Agile team.

For the Software 2020 User’s Guide and all documents and information go to our Document Download page.



2. Let’s Get Started

2.1. Initial Setup

For basic tenant and user setup, see the Software 2020 Admin User Guide and perform the setup steps before using the system.

2.2. Setting up your Profile the First Time

If you are Test Driving, please do not change the demo user’s profile information as this could block other users from being able to Test Drive until we refresh the system.

For all other users, Click the <myname>’s Profile nav link to go to your Profile page to make sure the parameters are set the way you want.

Add your First and Last Name, verify your email is correct. Post a profile picture so others know who you are.



Set your “Task Defaults” for how you typically want to enter your new tasks. Here product designers would typically default their new tasks as Enh (which are automatically set to “Spec” when associated to a Story or Spec document); QA may set their default to “Bug”.

You may also want to click the “My Notification Rules” link to set up your email notifications so that Software 2020 performs for you as a valuable communications hub.



3. Agile Story Management Tools

3.1. Adding Stories

Let’s assume this is a new project. First, you need to create a list of user stories or features you want to implement in the future.

Let’s start adding stories.

We group stories into documents or “specs”. So first create a new document, then enter your stories.

Click the “Organize” tab to create your first Story spec. Here we’re going to create a new document for our Stories (Click “Create New Spec”). (Note – you can easily change this via Resources to “Create New Stories” or whatever maps into your own process.)

Now you can open the new doc and start adding your functions or epics and stories.

You can enter the Epic as a “Header” or just add all in the spec without hierarchy.



To add Stories for this Epic, click “Add Task” Action, the add task pop-‐up comes up. Conveniently the ‘settings’ default based on the spec but to save time you can update them here – or leave the defaults and manage them later.

If you click the “Save & Add” button, the next story will be right below and will use the same values as the current story. When you are done you have your set of Epics and Stories ready for estimation and grooming.

3.2. Add the Conditions of Satisfaction (COS) and Prioritize

Before estimation, the PO will probably want to enter COS (Conditions of Satisfaction)



and perhaps Priority or other information. (*) Refer to the User Guide Appendix for more about the recommended process for handling statuses and other enumerated fields.

3.3. Estimating Stories

Now the PO is ready to hold a planning and estimating meeting with the development team. The Spec Detail screen is an easy way to review the stories, drill in to view story details like the COS, any existing comments or discussions, and update story points.

On the Organize Detail screen, review the stories and enter Story Points easily.

3.4. Estimating Velocity

The PO can have the system calculate past sprint velocities (Release 1.0) or enter the past history of velocities/sprint manually and the system will calculate maximum and minimum team velocity per sprint and chart the range of points that can be accomplished in the next “N” sprints. This is used to help groom how many stories are likely to be able to be completed for this sprint and for the total release.



3.5. Ranking Tool

The ranking tool helps the PM rank the stories so developers know what stories to start work on first.

Users can drag & drop the tasks to organize what's above the red bar (what's in the release for sure) and rank for which dev should do first (top to bottom) and "Save" -‐ the new rankings (top one=1, next one=2, ... red bar has a rank per Release#). Next user sees same rank -‐ it's permanent.

3.6. Grooming Stories

Once the velocity and ranking are determined, the team decides what stories should be assigned to the first few sprints. In addition, they prioritize which stories are likely to make the release versus the stretch/backlog stories. Stories that are unlikely to be in this release are left Open-‐Spec or Open-‐Eval. (*) Refer to the Appendix for more about the recommended process for handling statuses and other enumerated fields.



3.7. Assigning Stories to Developers

Stories that are planned for this release are set to open-‐fix to the appropriate developer. Stories for the first few sprints are assigned Target Phase=”Sprint 1”, “Sprint 2” (not all sprints, just the first few). The managers can check the sprints by evaluating the total sprint points (using the Spec Detail screen search filters by sprint and the totals at the bottom of the screen).

Process Note: Developers should be trained to only work on Tasks that are open-‐fix, assigned to them and for the current release and sprint. (*) Refer to the Appendix for more about the recommended process for handling statuses and other enumerated fields.



4. Tracking the Development Effort

4.1. Using Task Tracker

Task Tracker lets the development manager and team have a holistic view of all of their work.

4.2. Creating New Tasks (Bugs, New Feature Requests)

For Tasks not created initially as a story (e.g., bugs), the new task is created from the Task Tracker screen.

• Found By defaults to “Internal” for internal users, the client name for client users. • Target Client defaults to “General” for internal users, the client name for client users. • Otherwise, Target Release defaults to “TBD”, Status to open-‐new, Assignments default to those in

setup by the tenant’s administrator.



The administrator will have also established what the list of Release Numbers are, the “Areas” that tasks are categorized in, and other parameters including what classification of tasks requires “Steps to Reproduce” (STR). Best practices is that all Bugs require STR.

4.3. Managing Tasks

4.3.1. Recommended Process

We recommend all new non-‐story tasks stay in release=TBD until a cross-‐functional group reviews them to assign to a release and priority. This would be, for example, issues found by customers or the services teams affecting existing software which may need to get added into a current sprint cycle. We call this cross-‐functional group the SDRB – Software Design Review Board – which is typically comprised of representatives from Product Marketing (the Product Owners), Development, Services, Tech Support and QA – and assign them to a release and assignee. We find this process avoids revisiting the same tasks over and over and wasting time. These Tasks wouldn’t be part of the Scrum Team Meetings until they were accepted as part of a current release and sprint.

The out-‐of-‐the-‐box statuses and stages are shown below.

Status Description Action Stage TBD The Task is new and hasn’t been allocated yet.

No work should begin. Review by POs or development managers and assigned Open*.

TBD

Open-‐Eval Needs to be reviewed. If assigned to a developer, they answer in the comments and assign back to the requester.

Open

Open-‐Spec Ready for Story development. These should be assigned to the PO for story/spec clarification

PO updates the Story/COS. Open

Open-‐Fix Ready to be implemented. Assigned to the implementer.

Implement when assigned to the Current Release and Sprint.

Open

Accepted The development team has accepted this task and assigned it to a phase/sprint.

Implement when assigned to the Current Release and Sprint (and updates hours estimates).

Open

In-‐Progress The developer has started work. Developer implements (and updates hours estimates).

Open

Resolved Ready for Testing. The work is done and has been reviewed. The code has been checked into the code management system.

QA tests. Resolved

Tested The Task definition of done (DoD) has been validated.

Ready for release. Closed

<Misc> Other classes are available to identify Tasks that are closed for various reasons without code or documentation changes such as Dupl (duplicate), Can’t Dupl (can’t be duplicated),

None. Closed



Status Description Action Stage NAB (Not a Bug), NoFix, etc. which set status to Closed and set release = “N/A”.

Three simple rules for Developers:

Rule 1: Developers should only do coding if a task is assigned “Open-‐Fix” or “Re-‐Opened” to the current release and sprint.

Rule 2: Developers assigned to an “Open-‐Eval” task in the current release should answer the request (in the Task comments) and re-‐assign back to the requester

Rule 3: Developers set status to “In Progress” when they start their work (adding hour estimates if the manager is going to use any hours-‐based tools like the Completion Report) and set status to “Resolved” when work is done, code reviewed, and checked into the code management system.

4.3.2. Assignees

The Assignee is the person who is currently responsible for the task. The best way to use the Tracker is to embrace an active process where the assignees review all of their tasks assigned to current releases and perform the requested action.

• Tasks that are open-‐eval should NOT be implemented – the SDRB or others are simply asking a question or wanting an evaluation. Anyone assigned an “open-‐eval” task for the current release should review the comments and enter a new comment to give the feedback/information requested. Then the assignee assigns the task back to the requester.

• Tasks that are open-‐fix for the current release are to be implemented. If the developer has a question, they set the task open-‐eval and assign it back to the PO or others for more information or guidance.

This process facilitates communication and clean releases.

When the task is being implemented, typically the Developer = Assigned.

When the developer starts work on a task, he/she sets to status to “In-‐Progress”.

When completed and the code is checked into the appropriate code management system, they set the task to “Resolved”. It is then ready for QA.

Two statuses are available for QA: “Verified” for the first pass of testing; “Tested” when the task has been deemed to be completed acceptably.

4.3.3. Viewing Spec from the Task Detail

Spec tasks will have the Spec Name they are in displayed in the Task Detail screen in the “Spec” area as a hyperlink. Clicking on that Spec Name will take the user to the Spec View screen, expanded, and paged to



where the Spec Item they came from is on. Their item will be highlighted with red borderbox around it. (If they want to return they’d click the Recent Task # at the top of the screen).

4.3.4. Linking Bugs to Specs

Bugs, Gaps or other Tasks can be linked to one or more existing spec items. Say a bug was found. Tech Support looks up the spec item and links it to the bug (enters the Spec Task # in the linked task list on the bug Task Detail screen). If a Spec Task is linked to another Task, on the Task Detail you see both the Task # link and it’s SpecName link. If the user clicks the Task # link they go to the Task Detail for that Task. If they click the SpecName link next to the Task, they go to the spec view page that has that Task # with that spec item bordered in red.

4.3.5. Attachments

Tasks often have relevant files associated with them, therefore it is useful to attach external data to the Task.

To upload a file attachment(s) click the Upload button on Task Detail screen. You can upload multiple attachments and then click “Continue” to upload.



4.4. Date Estimator Tool

The Date Estimator gives managers a valid project for when the workload for their team will be completed.

They enter the start date and select the task criteria. Typically development teams have 60% of their day available; the other goes to meetings, discussions, and miscellany. It may sound to managers like this is too low – from years of experience, it is the ‘best fit’ percentage.

With Software 2020, the manager can adjust that percentage for each developer. Say one developer always over-‐estimates by 50% -‐ change that developer’s confidence percent. The chart shows how many tasks the developer actually estimated versus unestimated tasks. The manager can enter their “best guess” for the time of unestimated tasks to complete the analysis.

This chart presents the date of completion based on 100% effort plus the more actual/realistic date of completion based on percent load.

4.5. Stability Chart

The Stability and other charts help you manage throughout the process

Software 2020 Quick Start Guide for Agile ... - WordPress.com · Software 2020Quick Start Guide for...

Documents

Transcript of Software 2020 Quick Start Guide for Agile ... - WordPress.com · Software 2020Quick Start Guide for...