In the previous post, I explained how I use a branching strategy to manage deployments to UAT and production instances. I also explained how the branching could help to implement new features and user stories. In this post, I am going to explain how I break the project to smaller pieces to make the development more manageable and the benefits of doing so.
I never finish anything, unless I set a deadline for myself. Surprisingly, many of my successful friends are the same, and an important reason they are successful is because they set deadlines for their work. Visual Studio Team Services makes having deadlines (read milestones) and project planning really easy. In this post I am going to explain the way I use Visual Studio Team Services to manage my work.
At the top of my project management hierarchy are releases. For example, I create biweekly or monthly releases. Ideally, I do not associate production deployments to releases, meaning I might push changes to production sooner than the release date is due (maybe daily with continues integration and automatic deployments). But releases are a great way for me to group what features/user stories are deployed at each period. Also I restrict myself not to do any other feature outside of the current release. For example, if I finish features under this release sooner than the release date, I will not move any of the features from the next release to the current release. The following image shows the hierarchy of my work items:
A release for me is a deadline. For example, let’s assume the project is a single page web application for a marketing landing page, which should be done in two weeks. I create a release with the date "2016/12/10" (two weeks from today).
Each release is expanded by defining features. Obviously, features and their scope is defined by the business requirements. In the example, I would create a feature with the title:
Single Page Marketing Landing Page for Promotion “Dummy Promo”.
Note that this is a very simple example. In a larger project with a larger team, there will be multiple features for each release. Or, a single feature can only be implemented in multiple sprints within a release. I want to keep things simple in this post. So let's continue with our simple example.
Then I start creating user stories for this feature. In bigger teams, usually features and user stories are created by the business analysts (BAs) and passed down to developers. I like to keep this routine in my small projects too. In my simple example, I would probably create the following user stories:
Note that I am not really following any standard convention regarding the verbiage of these user stories.
I am only utilizing user stories to break down a feature to smaller components (goals). It is extremely important that if the user stories are vague or does not specify a single user story, they need to be discussed with the BAs (or revised by yourself) to be broken down to smaller, clearer user stories.
The next step is I put on my developer gloves and start thinking about tasks for each user story. When I create tasks, it is as if I have already started developing (read coding) the user stories. A lot of developers (including myself in the past) start thinking about the user story with the code editor open in front of them. Unfortunately, in my experience this will extremely effect both the quality of the code and the deadlines. Nowadays, I normally grab a piece of paper and draft how I am going to implement a user story (literally staying away from the code editor). Then I create tasks under the user story in Team Services. Let’s take the first user story in my simple example:
But this is so simple, boring and redundant! And I agree. As an experienced [web] developer I can just take the user story and start implementing it right away. What I am trying to highlight here is, I am already in the developer mode. Creating these tasks are part of my coding journey to develop the user story. If any of these tasks are dependent on other resources (for example I need to get the design assets from another team member/department), I can send an email about it to get the project going, rather than trying to resolve this issue in the middle of my coding and waiting for it to be resolved.
Breaking down user stories to smaller tasks has the following benefits:
Note that this post is about being in control of your development or as the title says Manageing the [development] Work. There is clearly a management overhead, specially in small projects, creating releases, features, and etc. But ultimately, with constant change of requirements in todays dynamic world, it will make change management much easier following these simple steps.
I must emphasize again, it is important to create the tasks based on the right user stories to provide more accurate effort estimates. If the user stories are not well defined (usually happens in bigger teams) they need to be revised to create distinction (separation of concerns in software engineering) between feature components.