Thursday, August 20, 2015

(3) SCRUM + Assignment 1


I really liked this week's class where Chris shared the tips about project management and introduction to agile and scrum. It got me thinking about user stories, something that my teammates also mentioned to me before. So after the talk, I wrote the user stories for our Assignment 1, and got feedback from my team that the expected outcome has be clearer than a generic one. Took in their advice and revised it~ yay


User stories

Oh, and Colin's talk on software development. On the part regarding the role of non-developers and developers. Now I think i have a better idea of how can I assist the group. Not just the marketing, but also to test out the apps. I now try to do abit of designing as well so that I can work on the UI/UX to improve the user's experience.

Update on the Assignment 1:
As of now, I'm fairly positive about it. I like the idea, and things are going well.
I wanted contribute more so I dabbled a little into design and that was pretty fun. (though it took me a while to figure out how to use sketch + get icons/resources+ how to make things nice). I also read up about UI/UX. I crafted out the mockups and flow of the app, from pages to pages, and I think it provides a good visualisation of our app. But while doing it, it sort of confirmed one of my concerns.

I feel that our app is bloating up. (see below.)
say hi to bloated fat cat meow~
Our app tries to do a lot. But what's holding me back is that I see the complete story of the app with these added features which are useful and justified. From a business standpoint, the idea will sell if the story is compelling. Furthermore, i see the developers of my team really want to make it work. But if you ask me, I still feel that such scale seems to be more suitable for the final project. We see how it goes, gonna have a meeting with my team tomorrow. For this project, I would say team's priority should be on the UI/UX than having more features, as reminded by Suyuen on Facebook.

Ciao
Mei Lan

5 comments:

  1. Well yeah I focused on the role of non-programmers because all the programmers have gone through Software Engineering and know all the stuff on the slides.. but they know VERY LITTLE about non-programming roles within a software team.

    Considering how my class is like 80% programmer, I thought talking about non-programming roles is much more important.

    As for your app.. you need to list down all the features, prioritize them, then cut two lines through the list. The first line is your MVP line. Everything above that line MUST be completed before submission and MUST be well done. The second line is the SHOULD HAVE line. Everything between the MVP line and the SHOULD HAVE line can be done (in order of priority) after the MVP items are well done enough.

    Everything below that can be moved to the final project (or implemented if there is time).

    ReplyDelete
  2. Well yeah I focused on the role of non-programmers because all the programmers have gone through Software Engineering and know all the stuff on the slides.. but they know VERY LITTLE about non-programming roles within a software team.

    Considering how my class is like 80% programmer, I thought talking about non-programming roles is much more important.

    As for your app.. you need to list down all the features, prioritize them, then cut two lines through the list. The first line is your MVP line. Everything above that line MUST be completed before submission and MUST be well done. The second line is the SHOULD HAVE line. Everything between the MVP line and the SHOULD HAVE line can be done (in order of priority) after the MVP items are well done enough.

    Everything below that can be moved to the final project (or implemented if there is time).

    ReplyDelete
    Replies
    1. Yes! We did that by drawing the spectrum of users, analysed what exactly each type of users want, then focus on the just two types of users whose's need converges. Now we have a clearer focus and a more streamlined approach.

      Delete
  3. The way to go about this is to:

    1) List down ALL the features one by one
    2) For each feature, ask yourself this question: Would the app be solving the problem without this feature? If yes, chop it off. If ya.. somewhat, chop it off.
    3) Keep doing this until you have 2-3 main features max.

    When Whatsapp first started, all they had was a messaging system, AND the mechanism for adding your friends through their mobile number. That's it! What problem did they solve? the difficulty of having to ASK and add all your friend's MSN ID, Skype ID, ICQ, etc manually. They focused on the core problem and solved it REALLY well with just one feature, and that was enough to propel them to virality :)

    ReplyDelete
    Replies
    1. Yup took that in mind! We have since chopped off some features hahaha which felt good cause' we did realised we are bloating the app.. Thanks! :)

      Delete