Polarion Software Weblog

Intro

In this Blog series I will try to reveal new ways to improve your requirements process – regardless of your starting point or requirements process. In this post I will define the requirements process and outline the various capture methods available today. In future posts we’ll look at the pros and cons of various common approaches used by organizations today to manage requirements, from the simplest manual process, to agile processes used in software development organizations, through to the most formal requirements process – and in each case, outline ways Polarion Requirements can be leveraged to better each process method.

Finally, for organizations that are approaching the requirements discipline for the first time, or who have a requirements process that is in-between the processes we’ve described – not too agile or not formal – I will share some recommended best practices for requirements management that we at Polarion have cultivated through our own experience in developing software, all of which can be easily enabled with Polarion Requirements or Polarion ALM Enterprise and implemented within any organization.

Why requirements?

In computing science terms, requirements management remains an immature discipline. While best practices surrounding the requirements management process and tooling continue to advance, there is tremendous opportunity for organizations to tighten up their product development process through greater maturity of the requirements management discipline.

Failure to properly define and manage requirements is often at the root of software project and product failure. It is a business reality that customers and management rarely know, or can describe in exact terms what they want at the end of the day. And too often, these same business sponsors will change their mind midstream – causing requirements to change. The impact of change even early in the project causes a downstream ripple effect, impacting project schedules, deadlines, delivery dates, and staffing commitments.

The ultimate goal of requirements management is, at the end of the day, to ensure that the final product meets the needs of the business. While this seems like a simple task, the process of articulating business needs or specifications, especially for complex products or software applications, is immensely difficult and requires significant elicitation and communications expertise plus advanced technologies to absorb, and manage detailed requirements and groups of requirements through to successful product/project delivery.

Organizations are individual in their approach to requirements management. Some companies and teams continue to rely upon manual processes – opting for a simple, tool-free approach that costs nothing and presents no learning curve. Others, such as a software development team who have embraced an agile development process, such as SCRUM and XP, demand a more fluid and transparent requirements process and lightweight tools that allow for iteration and frequent change. And finally, there are organizations with complex product development processes or in regulated industries that need a highly formalized and rigid requirements process and significant tooling support.

(more…)

by Nick Entin

Sprint Development

During a sprint, the development team continuously integrates all changes, and updated versions of the product are installed on the internal servers daily to prove stability and allow earlier testing of new functionality by other people (testers, doc writers, etc.)

The Polarion development process stipulates the following:

• An integration build is run at least once per day (usually nightly).
• In case of build failure, the problems need to be fixed ASAP and a new build triggered.
• Failed unit tests should be treated with highest priority, and a build should be triggered again to confirm fixes of the unit tests.
• 20% of each iteration’s development time is reserved as buffer for unpredicted activities (e.g. a critical defect or failed unit tests, or an urgent support request from a customer)
• If for some reason the buffer is exceeded, or senior management requires execution of some unplanned items, the iteration should be cancelled and a new plan created.

(more…)

by Michael Carey

Many people reading this post will have seen this image before:

The Polarion Software logo, right? But do you know what it represents and why? Here’s a hint:

You guessed it: Polarion’s logo represents the Aurora Borealis, commonly known as the northern lights. Not to disparage our friends “down under” who have the Aurora Australis, or southern lights (an equally inspiring sight), but we chose north because the name of our company derives from “Polaris”, also known as the “North star” or “Pole star”. And why on Earth (or off Earth as the case may be) did we pick that?

(more…)

Sprint Meetings

Meetings are possibly the most important assets of Scrum. As described in previous chapters, Scrum allows us to identify problems and help find ways resolve them. Meetings are the essential part when team commits to Product Owner on the amount of work (features) they will address over the sprint, they discuss the progress on Daily Scrums and, finally, access results on the end meeting.

In this post and the next I’ll describe how we manage those meetings with the Polarion development team.

Planning

The goal of the Planning Meeting is to ensure that the team fully understands the Product Backlog items, to commit the team to implementing agreed-on items in upcoming sprint, and to ensure proper distribution of work among team members.

Typically the meeting is split to two parts. The first part involves the Product Owner, and possibly other stakeholders, if required to clarify backlog items, ensure common understanding of things to be done and commit the team to some items. The second part is a rather internal meeting, where the team decides who will implement what. We check decomposition of User Stories to child User Stories, Tasks, Improvements, Defects and validate capacity of the team using the LivePlan feature of Polarion ALM which reveals over- and under- tasked people, potential bottlenecks, and dependencies as soon as we plug our tentative plan into the system.

Normally the User Stories in the Product Backlog are have been inspected by developers in advance, rough estimations have been given, so in the Planning Meeting team members come with prepared questions. BTW, they may also come in with concerns – e.g. if they feel that some functionality may conflict with some agreements or principles, or one described feature is inconsistent with some other.

Artifacts to be discussed during Planning Meeting include:

• Product Backlog Items (User Stories), in order of business demand
• User Stories should be estimated in advance ( by setting its Initial Estimate attribute in Polarion ALM), or if considered to be small, then concrete estimation might be agreed on in the meeting.

There are some preconditions discussed at the planning meeting . We don’t have a team where every developer can do whatever his colleague can do. Almost everybody has their own specialization and sometimes it happens that if a person is on vacation or sick, some area of functionality won’t be addressed efficiently during the sprint. So the team, together with the Product Owner, discuss if it makes sense to delegate the feature to somebody else and have lower performance, or if it will be better to postpone it to the next Sprint, waiting for the right specialist. Of course such issues are resolved on an individual basis.

Artifacts to be composed out of the Planning Meeting:

• Selected User Stories for the Sprint become a Time Point assignment

During the second part of the Meeting concrete tasks are checked and also remaining estimates for the User Stories are clarified.

Results of the planning meeting are presented in a wiki page:

(more…)

Product Backlog

by Nick Entin, VP Research & Development, Certified ScrumMaster

Typically Product Owner would write Excel or Word document with his items and then simply reshuffles them according priorities. Of course any ticketing system would allow management of such artifacts in good way, so does Polarion.

Composing User Stories

We use 3 ways of composing User Stories:

• Through Polarion Web UI (“Create WorkItem”)
• Through Email (send Email to Polarion Mailet)
• Through LiveDocs

In either way created WorkItems appear in Tracker and it’s relatively easy for all stakeholders to find them using our QueryBuilder (e.g. for our configuration a query might be “type:userstory AND backlog:usability“), or such queries might be included into a Wiki page:

Prioritizing of UserStories

This is the point where our process differs from typical. As mentioned above, we have several relatively independent stakeholders, who are committed to common goal, but somehow pursuit own target (known situation, isn’t it? ) I.e. we Support Lead might want to address integration with third-party software, because several customers are trying to implement it themselves and flooding support with relevant requests. Of course this guy knows that there are other important features or problems, but he doesn’t want to compare if his idea is more important or less.

In our case each backlog is prioritized separately by corresponding Backlog Owner. Also Backlog owner defines threshold of his items – those items must appear in the Product Backlog and, ideally, should be discussed by the team.

We created a Wiki page like the one shown in Figure 8 above, which collects those backlogs and visualizes the top items:

Extracting from specific Backlogs to Product Backlog

Next step should be to collect all the required items for the Product Backlog – it’s relatively easy to create Wiki, which collects all the “top” items from corresponding backlogs.

Next step will be to give Product Owner to prioritize the list – we’ve defined new custom field “Product Backlog Priority” (PBP) with type Integer, where PO may sort the items accordingly.

Nice thing in Polarion – you may click “More” in the Wiki’s table to open the WorkItems table. You may configure special Hat for Product Owner, or I use personal table settings to expose PBP column, so I can easily reshuffle items.

The PBP attribute also helps to track down if there were some changes in particular backlog, but not yet reflected in the Common one. I.e. a query, which lists all the “important” user stories, which don’t have the PBP initialized:

Additional tips from our development process

During creation of WorkItems, we actively use Autoassignment feature, which allows immediately select a Senior Developer, who potentially will be leading the implementation, he gets Email notification and see this new item assigned to him. This way we encourage early review of posted user stories, already filtered input for the planning meetings, etc.

For simplifying prioritization the “weight” or “initial estimate” of a UserStory is important and automatic assignment helps to get initial review and communication even before the Planning Meeting.

Also we’ve configured UserStories to aggregate Remaining Estimates from the children items.
It means that by brainstorming and agreement on the Planning Meeting we identify Initial Estimate of a UserStory. However later, when it is decomposed to Improvement, Tasks and Defects, one can recognize some variations, i.e. that particular work actually takes less time, or some additional task was not counted and discovered after implementation begin.
This data is extremely helpful for re-planning of the UserStory to next Sprint, if it wasn’t finished properly.

Note: we pay special attention to UserStories, which were committed to a Sprint, but was not completed properly. It’s very naturally to let it go to the next Sprint because “it’s just took a little longer than was planned, therefore it isn’t done yet”. Intuitive expectation is that as soon it’s moved to next Sprint, it will be done in the first day. No! Practice shows that developers quite often leave unfinished UserStories to end of iteration, because it’s easy to complete and they know exactly what to do. This, however, doesn’t match to reality – they get late with other tasks, and this UserStory remains unfinished this and may be next Sprint.

This is very popular question on our Planning Meeting: “If this UserStory was not addressed on last Sprint, how could we ensure that our new commitment to this UserStory will be really realized?”

Next time…

In the next post I’ll talk about Sprints and how we handle them in the Polarion development team.

---

Editor’s Note:
Nick Entin is VP for Research & Development at Polarion Software. He oversees the development of all Polarion requirements management, application lifecycle management, and team collaboration software products. He is a member of the Scrum Alliance and a Certified ScrumMaster. You can read his profile at http://www.polarion.com/company/people/index.php.

---